Logical Methods in Computer Science 
Vol. 4(4:12) 2008, pp. 1-67 
www.lmcs-online.org 



Submitted Dec. 16, 2006 
Published Nov. 29, 2008 



A RATIONAL DECONSTRUCTION 
OF LANDIN'S SECD MACHINE WITH THE J OPERATOR 

OLIVIER D AN VY a AND KEVIN MILLIKIN 6 

a Department of Computer Science, Aarhus University 
IT-parken, Aabogade 34, DK-8200 Aarhus N, Denmark 
e-mail address: danvy@brics.dk 

b Google Inc. 
Aabogade 15, DK-8200 Aarhus N, Denmark 
e-mail address: kmillikin@google.com 



Abstract. Landin's SECD machine was the first abstract machine for applicative ex- 
pressions, i.e., functional programs. Landin's J operator was the first control operator for 
functional languages, and was specified by an extension of the SECD machine. We present 
a family of evaluation functions corresponding to this extension of the SECD machine, us- 
ing a series of elementary transformations (transformation into continuation-passing style 
(CPS) and defunctionalization, chiefly) and their left inverses (transformation into direct 
style and refunctionalization) . To this end, we modernize the SECD machine into a bisimi- 
lar one that operates in lockstep with the original one but that (1) does not use a data stack 
and (2) uses the caller-save rather than the callee-save convention for environments. We 
also identify that the dump component of the SECD machine is managed in a callee-save 
way. The caller-save counterpart of the modernized SECD machine precisely corresponds 
to Thielecke's double-barrelled continuations and to Felleisen's encoding of J in terms of 
call/cc. We then variously characterize the J operator in terms of CPS and in terms of 
delimited-control operators in the CPS hierarchy. 

As a byproduct, we also present several reduction semantics for applicative expressions 
with the J operator, based on Curien's original calculus of explicit substitutions. These 
reduction semantics mechanically correspond to the modernized versions of the SECD 
machine and to the best of our knowledge, they provide the first syntactic theories of 
applicative expressions with the J operator. 

The present work is concluded by a motivated wish to see Landin's name added to the 
list of co-discoverers of continuations. Methodologically, however, it mainly illustrates the 
value of Reynolds's defunctionalization and of refunctionalization as well as the expres- 
sive power of the CPS hierarchy (1) to account for the first control operator and the first 
abstract machine for functional languages and (2) to connect them to their successors. 
Our work also illustrates the value of Danvy and Nielsen's refocusing technique to con- 
nect environment-based abstract machines and syntactic theories in the form of reduction 
semantics for calculi of explicit substitutions. 
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1. Introduction 

Forty years ago, Peter Landin unveiled the first control operator, J, to a heretofore 
unsuspecting world [81,82,84]. He did so to generalize the notion of jumps and labels for 
translating Algol 60 programs into applicative expressions, using the J operator to account 
for the meaning of an Algol label. For a simple example, consider the block 

begin s\ ; goto L ; L : s 2 end 

where the sequencing between the statements ('basic blocks,' in compiler parlance [8]) si 
and s 2 has been made explicit with a label and a jump to this label. This block is translated 
into the applicative expression 

A().let L = J s 2 in let () = si () in L () 

where s'i and s 2 respectively denote the translation of si and s 2 . The occurrence of J 
captures the continuation of the outer let expression and yields a 'program closure' that is 
bound to L. Then, s[ is applied to (). If this application completes, the program closure 
bound to L is applied: (1) s' 2 is applied to () and then, if this application completes, (2) 
the captured continuation is resumed, thereby completing the execution of the block. 

Landin also showed that the notion of program closure makes sense not just in an 
imperative setting, but also in a functional one. He specified the J operator by extending 
the SECD machine [80,83]. 

1.1. The SECD machine. Over the years, the SECD machine has been the topic of 
considerable study: it provides an unwavering support for operational semantics [1, 9, 11, 
19,25,26,53,68,69,74,95,100,117], compilation [5,10,21,23,62,64,65,96,98,99,106], and 
parallelism [2,20], and it lends itself readily to variations [47,48,51,67,101,105,116] and 
generalizations [87,88,120]. In short, it is standard textbook material [55,63,70,71,79,109], 
even though its architecture is generally agreed to be on the 'baroque' side, since most 
subsequent abstract machines have no data stack and only one control stack instead of 
two. Nobody, however, seems to question its existence as a distinct artifact (i.e., man- 
made construct) mediating between applicative expressions (i.e., functional programs) and 
traditional sequential imperative implementations. 

Indeed abstract machines provide a natural meeting ground for theoretically-minded 
and experimentally-minded computer scientists: they are as close to an actual implementa- 
tion as most theoreticians will ever get, and to an actual formalization as most experimen- 
talists will ever go. For example, Plotkin [100] proved the correctness of the SECD machine 
in reference to a definitional interpreter due to Morris [91] and a variety of implementations 
take the SECD machine as their starting point [10,20,23,87]. 

1.2. The authors' thesis. Is there, however, such a gap between applicative expressions 
and abstract machines? The thrust of Steele's MSc thesis [110] was that after CPS trans- 
formationj^ a A-abstraction can be seen as a label and a tail call as a machine jump with the 

ll CPS' stands for 'Continuation-Passing Style;' this term is due to Steele [110]. In a CPS program, all calls 
are tail calls and functions thread a functional accumulator, the continuation, that represents 'the rest of the 
computation' [114]. CPS programs are either written directly or the result of a CPS transformation [39, 100]. 
(See Appendix 1X21) The left inverse of the CPS transformation is the direct-style transformation [33,41]. 
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machine registers holding the actual parameters. Furthermore the point of Reynolds's de- 
functionalization [102] is that higher-order programs can be given an equivalent first-order 
representation 

It nevertheless took 40 years for the SECD machine to be 'rationally deconstructed' 
into a compositional evaluation function [35], the point being that 

(1) the SECD machine is essentially in defunctionalized form, and 

(2) its refunctionalized counterpart is an evaluation function in CPS, which turns out to be 
compositional. 

This deconstruction laid the ground for a functional correspondence between evaluators and 
abstract machines [3, 4, 6, 7, 13, 16, 36, 37, 73, 89, 90, 93] . 

It is therefore the authors' thesis [36, 90] that the gap between abstract machines and 
applicative expressions is bridged by Reynolds's defunctionalization. 

Our goal here is to show that the functional correspondence between evaluators and 
abstract machines also applies to the SECD machine with the J operator, which, as we 
show, also can be deconstructed into a compositional evaluation function. As a corollary, 
we present several new simulations of the J operator, and the first syntactic theories for 
applicative expressions with the J operator. 

1.3. Deconstruction of the SECD machine with the J operator. Let us outline 
our deconstruction of the SECD machine before substantiating it in the next sections. We 
follow the order of the first deconstruction [35], though with a twist: for simplicity and 
without loss of generality, in the middle of the derivation, we first abandon the stack- 
threading, callee-save features of the SECD machine, which are non-standard, for the more 
familiar — and therefore less 'baroque' — stackless, caller-save features of traditional defini- 
tional interpreters [59,91,102,111]. (These concepts are reviewed in the appendices. The 
point here is that the SECD machine manages the environment in a callee-save fashion.) 
We then identify that the dump too is managed in a callee-save fashion and we present the 
corresponding caller-save counterpart. 

The SECD machine is defined as the iteration of a state-transition function operating 
over a quadruple — a data stack (of type S) containing intermediate values, an environment 
(of type e), a control stack (of type C), and a dump (of type d) and yielding a value (of type 
value): 

run : S*E*C*D-> value 
The first deconstruction [35] showed that together the C and D components represent the 
current continuation and that the D component represents the continuation of the current 
caller, if there is one. As already pointed out in Section since Landin's work, the C and 
D components of his abstract machine have been unified into one component; reflecting this 
unification, control operators capture both what used to be C and D instead of only what 
used to be D. 



In the early 1970's [102], John Reynolds introduced defunctionalization as a variation of Landin's 'func- 
tion closures' [80], where a term is paired together with its environment. In a defunctionalized program, 
what is paired with an environment is not a term, but a tag that determines this term uniquely. In ML, 
the tagged environments are grouped into data types, and auxiliary apply functions dispatch over the tags. 
(See Appendix IA. 31 ) The left inverse of defunctionalization is 'refunctionalization' [43,44]. 
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1.3.1. Disentangling and refunctionalization (Section^). The above definition of run looks 
complicated because it has several induction variables, i.e., it dispatches over several com- 
ponents of the quadruple. Our deconstruction proceeds as follows: 

• We disentangle run into four mutually recursive transition functions, each of which has 
one induction variable, i.e., dispatches over one component of the quadruple (boxed in 
the signature below): 

run_c : S*E*[c]*D-> value 

run_d : value * [d] -> value 

run_t : |term| *S*E*C*D-> value 

run_a : |value| * value *S*E*C*D-> value 

The first function, run_c, dispatches towards run_d if the control stack is empty, run_t if the 
top of the control stack contains a term, and run_a if the top of the control stack contains 
an apply directive. This disentangled specification, as it were, is in defunctionalized 
form [43,44,102]: the control stack and the dump are defunctionalized data types, and 
run.c and run_d are the corresponding apply functions. 

• Refunctionalization eliminates the two apply functions: 

run_t : term *S*E*C*D-> value 

run_a : value * value *S*E*C*D-> value 
where C=S*E*D-> value and D = value -> value 

C and D are now function types. As identified in the first rational deconstruction [35], the 
resulting program is a continuation-passing interpreter. This interpreter threads a data 
stack to hold intermediate results and uses a callee-save convention for environments to 
process subterms. (For information and comparison, Appendix[B]illustrates an interpreter 
with no data stack for intermediate results and a caller-save convention for environments, 
Appendix [O illustrates an interpreter with no data stack for intermediate results and a 
callee-save convention for environments, and Appendix [D] illustrates an interpreter with 
a data stack for intermediate results and a caller-save convention for environments.) 
At this point, we could continue as in the first deconstruction [35] and exhibit the direct- 
style counterpart of this interpreter. The result, however, would be less simple and less 
telling than first making do without the data stack (Section II .3.2|) and second adopting the 
more familiar caller-save convention for environments (Section ll.3.3j) before continuing the 
deconstruction towards a compositional interpreter in direct style (Section II .3.4[) . 

1.3.2. A first modernization: eliminating the data stack (Section^. In order to focus on 
the nature of the J operator, we first eliminate the data stack: 

run_t : term * E * C * D -> value 

run_a : value * value * E * C * D -> value 
where C = value * E * D -> value and D = value -> value 

(Two simpler interpreters are presented and contrasted in Appendices iBl and |Pl The first, 
in Appendix[Hl has no data stack for intermediate results, and the second, in Appendix ITU 
has one.) 



A RATIONAL DECONSTRUCTION OF LANDIN'S SECD MACHINE WITH THE J OPERATOR 5 



1.3.3. A second modernization: from callee-save to caller-save environments (Section^). 
Again, in order to focus on the nature of the J operator, we adopt the more familiar caller- 
save convention for environments. In passing, we also rename run_t as eval and run_a as 
apply: 

eval : term * E * C * D -> value 

apply : value * value * C * D -> value 
where C = value * D -> value and D = value -> value 

(Two simpler interpreters are presented and contrasted in Appendices[B]andO The first, in 
Appendix[Bj uses a caller-save convention for environments, and the second, in Appendix ICj 
uses a callee-save convention.) 

1.3.4. Continuing the deconstruction: towards a compositional interpreter in direct style. 

• A direct-style transformation eliminates the dump continuation: 

eval : term * E * C -> value 

apply : value * value * C -> value 
where C = value -> value 

The clause for the J operator and the main evaluation function are expressed using the 
delimited-control operators shift and reset [38] H The resulting interpreter still threads 
an explicit continuation, even though it is not tail-recursive. 

• Another direct-style transformation eliminates the control continuation: 

eval : term * E -> value 

apply : value * value -> value 

The clauses catering for the non-tail-recursive uses of the control continuation are ex- 
pressed using the delimited-control operators shift i, reset i, shifty, and reset2 [13,38,46, 
75,94]. The resulting evaluator is in direct style. It is also in closure-converted form: the 
applicable values are a defunctionalized data type and apply is the corresponding apply 
function. 

• Refunctionalization eliminates the apply function: 

eval : term * E -> value 
The resulting evaluation function is compositional, and the corresponding syntax-directed 
encoding gives rise to new simulations of the J operator. 

1.3.5. A variant: from callee-save to caller-save dumps (Section^. In Section ll.3.31 we kept 
the dump component because it is part of the SECD machine semantics of the J operator. 
We observe, however, that the dump is managed in a callee-save way. We therefore change 
gear and consider the caller-save counterpart of the interpreter: 

eval : term * E * C * D -> value 

apply : value * value * C -> value 

where C = value -> value and D = value -> value 

^ Delimited continuations represent part of the rest of the computation: the control operator reset 
delimits control and the control operator shift captures the current delimited continuation [38]. These 
two control operators provide a direct-style handle for programs with two layers of continuations. This 
programming pattern is also used for 'success' and 'failure' continuations in the functional-programming 
approach to backtracking. Programs that have been CPS-transformed twice exhibit two such layers of 
continuations. Here, C is the first layer and D is the second. Iterating a CPS transformation gives rise to a 
CPS hierarchy [13,38,76,94]. 
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This caller-save interpreter is still in CPS. We can write its direct-style counterpart and 
refunctionalize its applicable values, which yields another compositional evaluation function 
in direct style. This compositional evaluation function gives rise to new simulations of the 
J operator, some of which had already been invented independently. 

1.3.6. Assessment. As illustrated in Sections 11.3.21 [T.3.31 and 11,3.51 there is plenty of room 
for variation in the present deconstruction. Each step is reversible: one can CPS-transform 
and defunctionalize an evaluator and (re)construct an abstract machine [3,4,6,7,13,16,35- 
37]. 

1.4. Syntactic theories of applicative expressions with the J operator. Let us 

outline our syntactic theories of applicative expressions substantiating them in the next 
sections. 

1.4.1. Explicit, callee-save dumps (Section^. We present a reduction semantics for Curien's 
calculus of closures extended with the J operator, and we derivationally link it to the caller- 
save, stackless SECD machine of Section 17.11 

1.4.2. Implicit, caller-save dumps (Section^. We present another reduction semantics for 
Curien's calculus of closures extended with the J operator, and we derivationally link it to 
a version of the SECD machine which is not in defunctionalized form. 

1.4.3. Explicit, caller-save dumps (Section^). We outline a third reduction semantics for 
Curien's calculus of closures extended with the J operator, and we show how it leads towards 
Thielecke's double-barrelled continuations. 

1.4.4. Inheriting the dump through the environment f Section \10\) . We present a fourth re- 
duction semantics for Curien's calculus of closures extended with the J operator, and we 
derivationally link it to a version of the CEK machine that reflects Felleisen's simulation of 
the J operator. 

1.5. Prerequisites and domain of discourse: the functional correspondence. We 

mostly use pure ML as a meta-language. We assume a basic familiarity with Standard 
ML and with reasoning about pure ML programs as well as an elementary understand- 
ing of defunctionalization [43, 44, 102] and its left inverse, refunctionalization; of the CPS 
transformation [38,41,59,91,102,110] and its left inverse, the direct-style transformation; 
and of delimited continuations [13,38,46,56,75]. From Section [3.21 we use pure ML with 
delimited-control operators as a meta-language. 
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The source language of the SECD machine. The source language is the A-calculus, extended 
with literals (as observables) and the J operator. Except for the variables in the initial 
environment of the SECD machine, a program is a closed term: 
datatype term = LIT of int 

I VAR of string 

I LAM of string * term 

I APP of term * term 

I J 

type program = term 

The control directives. The control component of the SECD machine is a list of control 
directives, where a directive is a term or the tag APPLY: 
datatype directive = TERM of term I APPLY 

The environment. We use a structure Env with the following signature: 
signature ENV = sig 

type ' a env 

val empty : ' a env 

val extend : string * 'a * 'a env -> 'a env 
val lookup : string * ' a env -> ' a 
end 

The empty environment is denoted by Env. empty. The function extending an environment 
with a new binding is denoted by Env . extend. The function fetching the value of an identifier 
from an environment is denoted by Env. lookup. These functions are pure and total and 
therefore throughout, we call them without passing them any continuation, i.e., in direct 
style [40]. 

Values. There are five kinds of values: integers, the successor function, function closures, 
"state appenders" [21, page 84], and program closures: 
datatype value = INT of int 
I SUCC 

I FUNCLO of E * string * term 

I STATE_APPENDER of D 

I PGMCLO of value * D 
withtype S = value list (* data stack *) 

and E = value Env. env (* environment *) 

and C = directive list (* control *) 

and D = (S * E * C) list (* dump *) 

A function closure pairs a A-abstraction (i.e., its formal parameter and its body) and its 
lexical environment. A state appender is an intermediate value; applying it yields a program 
closure. A program closure is a first-class continuation^ 

The initial environment. The initial environment binds the successor function: 
val e_init = Env. extend ("succ", SUCC, Env. empty) 



The terms 'function closures' and 'program closures' are due to Landin [82]. The term 'state appender' 
is due to Burge [21]. The term 'continuation' is due to Wadsworth [118]. The term 'first-class' is due to 
Strachey [113]. The term 'first-class continuation' is due to Friedman and Haynes [58]. 
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The starting specification: Several formulations of the SECD machine with the J operator 
have been published [21,51,82]. We take the most recent one, i.e., Felleisen's [51], as our 
starting point, and we consider the others in Section [5[ 
(* run : S*E*C*D-> value 



run 

fun run (v : : 
= v 

run (v : : 
= run (v 
run ( s , e 



*) 



e, nil, nil) 



s', e' , 
: s, e, 



e , c) 



d) 



nil, (s 
c, d) 
(TERM (LIT n)) 
= run ((INT n) :: s, e, c 
run (s, e, (TERM (VAR x)) :: c 
= run ((Env. lookup (x, e)) :: 
run (s, e, (TERM (LAM (x, t))) 
= run ( (FUNCLD (e, x, t)) :: s, e, c, 
run (s, e, (TERM (APP (tO, tl))) :: c 
= run (s, e, (TERM tl) :: (TERM tO) : 
run (s, e, (TERM J) : : c, d) 



d) 



c, d) 

d) 
, e, 



c, d) 
d) 
d) 
d) 

APPLY 



c, d) 



(* 1 *) 



= run ( ( STATE_ APPENDER d) 
run (SUCC : : (INT n) : : s, 
= run ((INT (n+D) : : s, e 
run ((FUNCLO (e' , x, t)) : 
= run (nil, Env. extend (x, 
run ((STATE_ APPENDER d') : 
= run ( (PGMCLD (v, d')) : : 
run ((PGMCLO (v, d')) : : V : 
= run (v : : v' : : nil, e_init 

fun evaluateO t 

= run (nil, e_init, (TERM t) 



d) 
: c, 



d) 



APPLY 
d) 

: : s , e , APPLY 
e') , (TERM t) 
: : s , e , APPLY 
s, e, c, d) 
: : s , e , APPLY : 

APPLY : : nil, d') 

(* evaluateO 



c, d) 
nil, (s, e, 
c, d) 



c) 



d) 



c, d) 



(* 2 *) 



(* 3 *) 



program -> value *) 



nil, nil) 

The function run implements the iteration of a transition function for the SECD machine: 
(s, e, c, d) is a state of the machine and each clause of the definition of run specifies a 
state transition. 

The SECD machine is deterministic. It terminates if it reaches a state with an empty 
control stack and an empty dump; in that case, it produces a value on top of the data 
stack. It does not terminate for divergent source terms. It becomes stuck if it attempts 
to apply an integer or attempts to apply the successor function to a non-integer value, in 
that case an ML pattern-matching error is raised (alternatively, the codomain of run could 
be made value option and a fallthrough else clause could be added). The clause marked 
"1" specifies that the J operator, at any point, denotes the current dump; evaluating it 
captures this dump and yields a state appender that, when applied (in the clause marked 
"2"), yields a program closure. Applying a program closure (in the clause marked "3") 
restores the captured dump. 



1.6. Prerequisites and domain of discourse: the syntactic correspondence. We 

assume a basic familiarity with reduction semantics as can be gathered in Felleisen's PhD 
thesis [50] and undergraduate lecture notes [52] and with Curien's original calculus of clo- 
sures [14,31], which is the ancestor of calculi of explicit substitutions. We also review the 
syntactic correspondence between reduction semantics and abstract machines in Section [E] 
by deriving the CEK machine from Curien's calculus of closures for applicative order. 
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1.7. Overview. We first disentangle and refunctionalize Felleisen's version of the SECD 
machine (Section [2]). We then modernize it, eliminating its data stack and making go 
from callee-save to caller-save environments, and deconstruct the resulting specification 
into a compositional evaluator in direct style; we then analyze the J operator (Section [3|). 
Identifying that dumps are managed in a callee-save way in the modernized SECD machine, 
we also present a variant where they are managed in a caller-save way, and we deconstruct 
the resulting specification into another compositional evaluator in direct style; we then 
analyze the J operator (Section Overall, the deconstruction takes the form of a series of 
elementary transformations. The correctness of each step is very simple: most of the time, 
it is a corollary of the correctness of the transformation itself. 

We then review related work (Section [5|) and outline the deconstruction of the original 
version of the SECD machine, which is due to Burge (Section [6]). 

We then present a reduction semantics for the J operator that corresponds to the 
specification of Section [3] (Section [7]). We further present a syntactic theory of applicative 
expressions with the J operator using delimiters (Section[8]), and we show how this syntactic 
theory specializes to a reduction semantics that yields the abstract machine of Section 0] 
(Section [9]) and to another reduction semantics that embodies Felleisen's embedding of J 
into Scheme described in Section EL"5l (Section [TOl) . 

We then conclude (Sections fTTI and [121) . 



2. DECONSTRUCTION OF THE SECD MACHINE WITH THE J OPERATOR: 
DISENTANGLING AND REFUNCTIONALIZATION 



2.1. A disentangled specification. In the starting specification of Section 11.51 all the 

possible transitions are meshed together in one recursive function, run. As in the first 
rational deconstruction [35], we factor run into four mutually recursive functions, each with 
one induction variable. In this disentangled definition, run_c dispatches to the three other 
transition functions, which all dispatch back to run_c: 

• run.c interprets the list of control directives, i.e., it specifies which transition to take 
according to whether the list is empty, starts with a term, or starts with an apply directive. 
If the list is empty, it calls run_d. If the list starts with a term, it calls run_t, caching 
the term in an extra component (the first parameter of run_t). If the list starts with an 
apply directive, it calls run_a. 

• run_d interprets the dump, i.e., it specifies which transition to take according to whether 
the dump is empty or non-empty, given a valid data stack; run_t interprets the top term 
in the list of control directives; and run_a interprets the top value in the data stack. 

Graphically: 
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S*E*C*D-> value *) 

value * D -> value *) 

term *S*E*C*D-> value *) 

value * value *S*E*C*D-> value *) 



(* run_c 
(* run_d 
(* run_t 
(* run_a 
fun run_c (v :: s, e, nil, d) 

= run_d (v, d) 
I run_c (s, e, (TERM t) :: c, d) 

= run_t (t, s, e, c, d) 
I run_c (vO :: vl :: s, e, APPLY :: c, d) 

= run_a (vO, vl, s, e, c, d) 
and run_d (v, nil) 

= v 

I run_d (v, (s, e, c) :: d) 

= run_c (v :: s, e, c, d) 
and run_t (LIT n, s, e, c, d) 

= run_c ((INT n) :: s, e, c, d) 
I run_t (VAR x, s, e, c, d) 

= run_c ((Env. lookup (x, e)) :: s, e, c, d) 
I run_t (LAM (x, t) , s, e, c, d) 

= run.c ((FUNCLO (e, x, t)) :: s, e, c, d) 
I run_t (APP (tO, tl) , s, e, c, d) 

= run.c (s, e, (TERM tl) :: (TERM tO) :: APPLY :: c, d) 
I run_t (J, s, e, c, d) 

= run.c ( (STATE_APPENDER d) :: s, e, c, d) 
and run.a (SUCC, INT n, s, e, c, d) 

= run.c ((INT (n+1)) :: s, e, c, d) 
I run.a (FUNCLO (e', x, t) , v, s, e, c, d) 

= run.c (nil, Env. extend (x, v, e'), (TERM t) :: nil, (s, e, c) :: d) 
I run.a ( STATE. APPENDER d' , v, s, e, c, d) 

= run.c ((PGMCLO (v, d')) :: s, e, c, d) 
I run.a (PGMCLO (v, d'), V, s, e, c, d) 

= run.c (v :: v' :: nil, e.init, APPLY :: nil, d') 
fun evaluate 1 t (* evaluate 1 : program -> value *) 

= run.c (nil, e.init, (TERM t) :: nil, nil) 

By construction, the two machines operate in lockstep, with each transition of the origi- 
nal machine corresponding to two transitions of the disentangled machine. Since the two 
machines start in the same initial state, the correctness of the disentangled machine is a 
corollary of them operating in lockstep: 

Proposition 2.1 (full correctness). Given a program, evaluateO and evaluatel either both 
diverge or both yield values that are structurally equal. 

In the rest of this section, we only consider programs that yield an integer value, if any. 
Indeed we are going to modify the data type of the values as we go from abstract machine 
to evaluator, and we want a simple, comparable characterization of the results they yield. 

Furthermore, again for simplicity, we short-circuit four state transitions in the abstract 
machine above: 



I run.t (APP (tO, tl) , s, e, c, d) 

= run.t (tl, s, e, (TERM tO) :: APPLY :: c, d) 
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I run_a (FUNCLO (e', x, t) , v, s, e, c, d) 

= run_t (t, nil, Env. extend (x, v, e'), nil, (s, e, c) :: d) 

I run_a (PGMCLO (v, d'), V, s, e, c, d) 
= run_a (v, v' , nil, e_init, nil, d') 

fun evaluate 1 t 

= run_t (t, nil, e_init, nil, nil) 

2.2. A higher-order counterpart. In the disentangled definition of Section \2.1\ there are 
two possible ways to construct a dump — nil and consing a triple — and three possible ways 
to construct a list of control directives — nil, consing a term, and consing an apply directive. 
One could phrase these constructions as two specialized data types rather than as two lists. 

These data types, together with run_d and run.c as their apply functions, are in the 
image of defunctionalization. After refunctionalization, the higher-order evaluator reads as 
follows^ it is higher-order because c and d now denote functions: 
datatype value = INT of int 
I SUCC 

I FUNCLO of E * string * term 
I STATE_APPENDER of D 
I PGMCLO of value * D 
withtype S = value list (* data stack *) 

and E = value Env. env (* environment *) 

and D = value -> value (* dump continuation *) 

and C=S*E*D-> value (* control continuation *) 

val e_init = Env. extend ("succ", SUCC, Env. empty) 

(* run_t : term *S*E*C*D-> value *) 

(* run_a : value * value *S*E*C*D-> value *) 
fun run_t (LIT n, s, e, c, d) 
= c ((INT n) : : s, e, d) 
I run_t (VAR x, s, e, c, d) 

= c ((Env. lookup (x, e)) :: s, e, d) 
I run_t (LAM (x, t) , s, e, c, d) 

= c ((FUNCLO (e, x, t)) :: s, e, d) 
I run_t (APP (tO, tl) , s, e, c, d) 
= run_t (tl, s, e, fn (s, e, d) => 

run_t (tO, s, e, fn (vO :: vl :: s, e, d) => 
run_a (vO, vl, s, e, c, d) , d) , d) 
I run_t (J, s, e, c, d) 
= c ( (STATE_APPENDER d) :: s, e, d) 
and run_a (SUCC, INT n, s, e, c, d) 
= c ((INT (n+D) : : s, e, d) 
I run_a (FUNCLO (e', x, t) , v, s, e, c, d) 
= run_t (t, nil, Env. extend (x, v, e'), fn (v :: s, e, d) => d v, 
fn v => c (v : : s, e, d)) 



^Had we not short-circuited the four state transitions at the end of Section al! the resulting higher-order 
evaluator would contain four /^-redexes. Contracting these redexes corresponds to short-circuiting these 
transitions. 
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I run_a (STATE_APPENDER d' , v, s, e, c, d) 

= c ((PGMCLO (v, d')) :: s, e, d) 
I run_a (PGMCLO (v, d'), V, s, e, c, d) 

= run_a (v, v', nil, e_init, fn (v :: s, e, d) => d v, d') 
fun evaluate2 t (* evaluate2 : program -> value *) 

= run_t (t, nil, e_init, fn (v : : s, e, d) => d v, fn v => v) 

The resulting evaluator is in CPS, with two layered continuations c and d. It threads a 
stack of intermediate results (s), an environment (e), a control continuation (c), and a 
dump continuation (d). Except for the environment being callee-save, the evaluator follows 
a traditional eval-apply schema: run_t is eval and run_a is apply. Defunctionalizing it 
yields the definition of Section [2. II and as illustrated in Appendix [A] by construction, run_t 
and run_a in the defunctionalized version operate in lockstep with run_t and run_a in the 
refunctionalized version: 

Proposition 2.2 (full correctness). Given a program, evaluatel and evaluate2 either both 
diverge or both yield values; and if these values have an integer type, they are the same 
integer. 

3. DECONSTRUCTION OF THE SECD MACHINE WITH THE J OPERATOR: 
NO DATA STACK AND CALLER-SAVE ENVIRONMENTS 

We want to focus on J, and the non-standard aspects of the evaluator of Section [22] (the 
callee-save environment and the data stack) are a distraction. We therefore modernize this 
evaluator into a more familiar caller-save, stackless form [59,91,102,111]. Let us describe this 
modernization in two steps: first we transform the evaluator to use a caller-save convention 
for environments (as outlined in Section fl.3.21 and illustrated in Appendices [B] and [C]) , and 
second we transform it to not use a data stack (as outlined in Section 11.3.31 and illustrated 
in Appendices [B] and [D|) . 

The environments of the evaluator of Section 12.21 are callee-save because the apply func- 
tion run_a receives an environment e as an argument and "returns" one to its continuation 
c [8, pages 404-408]. Inspecting the evaluator shows that whenever run_a is passed a con- 
trol directive c and an environment e and applies c, then the environment e is passed to c. 
Thus, the environment is passed to run_a only in order to thread it to the control continu- 
ation. The control continuations created in run_a and evaluate2 ignore their environment 
argument, and the control continuations created in run_t are passed an environment that 
is already in their lexical scope. Therefore, neither the apply function run_a nor the control 
continuations need to be passed an environment at all. 

Turning to the data stack, we first observe that the control continuations of the evaluator 
in Section 12.21 are always applied to a data stack with at least one element. Therefore, we 
can pass the top element of the data stack as a separate argument, changing the type of 
control continuations from S * E * D -> value to value * S * E * d -> value. We can 
thus eliminate the data stack following an argument similar to the one for environments 
in the previous paragraph: the run_a function merely threads its data stack along to its 
control continuation; the control continuations created in run.a and evaluate2 ignore their 
data-stack argument, and the control continuations created in run_t are passed a data stack 
that is already in their lexical scope. Therefore, neither the apply function run_a, the eval 
function run_t, nor the control continuations need to be passed a data stack at all. 
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3.1. A specification with no data stack and caller-save environments. The caller- 
save, stackless counterpart of the evaluator of Section [2.21 reads as follows, renaming run_t 
as eval and run_a as apply in passing: 
datatype value = INT of int 
I SUCC 

I FUNCLO of E * string * term 
I STATE_APPENDER of D 
I PGMCLQ of value * D 
withtype E = value Env.env (* environment *) 

and D = value -> value (* dump continuation *) 

and C = value * D -> value (* control continuation *) 

val e_init = Env. extend ("succ", SUCC, Env. empty) 

(* eval : term * E * C * D -> value *) 

(* apply : value * value * C * D -> value *) 
fun eval (LIT n, e, c, d) 
= c (INT n, d) 
I eval (VAR x, e, c, d) 

= c (Env. lookup (x, e) , d) 
I eval (LAM (x, t) , e, c, d) 

= c (FUNCLO (e, x, t) , d) 
I eval (APP (tO, tl) , e, c, d) 
= eval (tl, e, fn (vl, d) => 
eval (tO, e, fn (vO, d) => 
apply (vO, vl, c, d) , d) , d) 
I eval (J, e, c, d) 

= c ( STATE_ APPENDER d, d) 
and apply (SUCC, INT n, c, d) 
= c (INT (n+1) , d) 
I apply (FUNCLO (e', x, t) , v, c, d) 
= eval (t, Env. extend (x, v, e'), fn (v, d) => d v, 
fn v => c (v, d) ) 
I apply (STATE_APPENDER d' , v, c, d) 

= c (PGMCLO (v, d') , d) 
I apply (PGMCLO (v, d'), V, c, d) 
= apply (v, v' , fn (v, d) => d v, d') 
fun evaluate2' t (* evaluate2' : program -> value *) 

= eval (t, e_init, fn (v, d) => d v, fn v => v) 

The new evaluator is still in CPS, with two layered continuations. In order to justify it 
formally, we consider the corresponding abstract machine as obtained by defunctionalization 
(shown in Section [7J the ML code for evaluate 1 ' is not shown here). This abstract machine 
and the disentangled abstract machine of Section 12.11 operate in lockstep and we establish 
a bisimulation between them. The full details of this formal justification are found in the 
second author's PhD dissertation [90, Section 4.4]. Graphically: 
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The following proposition follows as a corollary of the bisimulation and of the correctness 
of defunctionalization: 

Proposition 3.1 (full correctness). Given a program, evaluate2 and evaluate2' either 
both diverge or both yield values; and if these values have an integer type, they are the same 
integer. 

3.2. A dump- less direct-style counterpart. The evaluator of Section 13.11 is in continu- 
ation-passing style, and therefore it is in the image of the CPS transformation. In order to 
highlight the control effect of the J operator, we now present the direct-style counterpart 
of this evaluator. 

The clause for J captures the current continuation (i.e., the dump) in a state appender, 
and therefore its direct-style counterpart naturally uses the undelimited control operator 
call/cc [41]. With an eye on our next step, we do not, however, use call/cc but its delimited 
cousins shift and reset [13,38,46] to write the direct-style counterpart. 

Concretely, we use an ML functor to obtain an instance of shift and reset with value 
as the type of intermediate answers [46,56]: reset delimits the (now implicit) dump con- 
tinuation in eval, and corresponds to its initialization with the identity function; and shift 
captures it in the clauses where J is evaluated and where a program closure is applied. 
There is one non-tail call to eval, to evaluate the body of a A-abstraction; this context is 
captured by shift when J is evaluated: 
datatype value = INT of int 
I SUCC 

I FUNCLO of E * string * term 
I STATE_ APPENDER of D 
I PGMCLO of value * D 
withtype E = value Env.env (* environment *) 

and C = value -> value (* control continuation *) 



and D 



value -> value 



(* first-class dump continuation *) 



val e_init = Env. extend ("succ", SUCC, Env. empty) 

structure SR = make_Shif t_and_Reset (type intermediate_answer = value) 

(* eval : term * E * C -> value 

(* apply : value * value * C -> value 
fun eval (LIT n, e, c) 



*) 
*) 



= c (INT n) 
I eval (VAR x, e, c) 
= c (Env. lookup (x, e)) 
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I eval (LAM (x, t) , e, c) 

= c (FUNCLO (e, x, t)) 
I eval (APP (tO, tl) , e, c) 

= eval (tl, e, fn vl => eval (tO, e, fn vO => apply (vO, vl, c))) 
I eval (J, e, c) 

= SR. shift (fn d => d (c (STATE_APPENDER d) ) ) (* * *) 

and apply (SUCC, INT n, c) 

= c (INT (n+1)) 
I apply (FUNCLO (e\ x, t) , v, c) 

= c (eval (t, Env. extend (x, v, e ' ) , f n v => v) ) (* * *) 

I apply ( STATE_ APPENDER d, v, c) 

= c (PGMCLO (v, d)) 
I apply (PGMCLO (v, d) , v' , c) 

= SR. shift (fn d' => d (apply (v, v', fn v => v))) (* * *) 

fun evaluate3' t (* evaluate3' : program -> value *) 

= SR. reset (fn () => eval (t, e_init, fn v => v)) 

The dump continuation is now implicit and is accessed using shift. The first occurrence 
of shift captures the current dump when J is evaluated. The second occurrence is used 
to discard the current dump when a program closure is applied. CPS-transforming this 
evaluator yields the evaluator of Section 13.11 

Proposition 3.2 (full correctness). Given a program, evaluate2' and evaluate3' either 
both diverge or both yield values; and if these values have an integer type, they are the same 
integer. 



3.3. A control-less direct-style counterpart. The evaluator of Section [3721 still threads 
an explicit continuation, the control continuation. It however is not in continuation-passing 
style because of the non-tail calls to c, eval, and apply (in the clauses marked "*" above) 
and the occurrences of shift and reset. This pattern of control is characteristic of the CPS 
hierarchy [13,38,46,75] (see also Footnote EJ page [5]). We therefore use the delimited- 
control operators shift i, reset i, shifty, and reset2 to write the direct-style counterpart of 
this evaluator (shifty and reset2 are the direct-style counterparts of shift i and reset i, and 
shift i and reset i are synonyms for shift and reset). 

Concretely, we use two ML functors to obtain layered instances of shift and reset with 
value as the type of intermediate answers [46,56]: reset2 delimits the (now twice implicit) 
dump continuation in eval; shifty captures it in the clauses where J is evaluated and where 
a program closure is applied; reseti delimits the (now implicit) control continuation in eval 
and in apply, and corresponds to its initialization with the identity function; and shifti 
captures it in the clause where J is evaluated: 
datatype value = INT of int 
I SUCC 

I FUNCLO of E * string * term 

I STATE_ APPENDER of D 

I PGMCLO of value * D 
withtype E = value Env. env (* environment *) 

and D = value -> value (* first-class dump continuation *) 

val e_init = Env. extend ("succ", SUCC, Env. empty) 

structure SRI = make_Shif t_and_Reset (type intermediate_answer = value) 
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structure SR2 = make_Shif t_and_Reset_next (type intermediate_answer = value 

structure over = SRI) 

(* eval : term * E -> value *) 

(* apply : value * value -> value *) 
fun eval (LIT n, e) 
= INT n 
I eval (VAR x, e) 

= Env. lookup (x, e) 
I eval (LAM (x, t) , e) 

= FUNCLO (e, x, t) 
I eval (APP (tO, tl) , e) 

= let val vl = eval (tl, e) 
val vO = eval (tO, e) 
in apply (vO, vl) end 
I eval (J, e) 

= SRI. shift (fn c => SR2 . shift (fn d => d (c (STATE_APPENDER d) ) ) ) 
and apply (SUCC, INT n) 
= INT (n+1) 
I apply (FUNCLO (e', x, t) , v) 

= SRI. reset (fn () => eval (t, Env. extend (x, v, e'))) 
I apply (STATE_APPENDER d, v) 

= PGMCLO (v, d) 
I apply (PGMCLO (v, d) , v') 

= SRI. shift (fn c' => SR2. shift (fn d' => 

d (SRI. reset (fn () => apply (v, v'))))) 
fun evaluated t (* evaluated : program -> value *) 

= SR2. reset (fn () => SRI. reset (fn () => eval (t, e_init))) 

The control continuation is now implicit and is accessed using shift i. The dump continuation 
is still implicit and is accessed using shifty. CPS-transforming this evaluator yields the 
evaluator of Section 13.21 

Proposition 3.3 (full correctness). Given a program, evaluate3' and evaluated either 
both diverge or both yield values; and if these values have an integer type, they are the same 
integer. 



3.4. A compositional counterpart. We now turn to the data flow of the evaluator of 
Section 13.31 As for the SECD machine without J [35] , this evaluator is in defunctionalized 
form: each of the values constructed with SUCC, FUNCLO, PGMCLO, and STATE_APPENDER is 
constructed at exactly one place and consumed at exactly one other (the apply function). 
We therefore refunctionalize them into the function space value -> value, which is shaded 
below: 

datatype value = INT of int 

I FUN of value -> value 
withtype E = value Env . env 

val e_init = Env. extend ("succ", FUN (fn (INT n) => INT (n+1)), Env. empty) 
structure SRI = make_Shif t_and_Reset (type intermediate_answer = value) 
structure SR2 = make_Shif t_and_Reset_next (type intermediate_answer = value 

structure over = SRI) 
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(* eval : term * E -> value *) 
(* where E = value Env.env *) 
fun eval (LIT n, e) 
= INT n 
I eval (VAR x, e) 

= Env. lookup (x, e) 
I eval (LAM (x, t) , e) 

= FUN (fn v => SRI. reset (fn () => eval (t, Env. extend (x, v, e)))) 
I eval (APP (tO, tl) , e) 
= let val vl = eval (tl, e) 

val (FUN f) = eval (tO, e) 
in f vl end 
I eval (J, e) 
= SRI. shift (fn c => SR2. shift (fn d => 
d (c (FUN (fn v => 

FUN (fn v' => SRI. shift (fn c' => 

SR2. shift (fn d' => 

d (SRI. reset (fn () => let val (FUN f) = v 

in f v' end)))))))))) 
fun evaluated' t (* evaluated' : program -> value *) 

= SR2. reset (fn () => SRI. reset (fn () => eval (t, e_init))) 

Unlike all the abstract machines and evaluators before, this evaluation function is com- 
positional: all the recursive calls on the right-hand side are over proper sub-parts of the 
corresponding expression on the left-hand side. Defunctionalizing this evaluation function 
yields the evaluator of Section 13.31 

Proposition 3.4 (full correctness). Given a program, evaluated and evaluated ' either 
both diverge or both yield values; and if these values have an integer type, they are the same 
integer. 



3.5. Assessment. From Section r3.1l to Section [374"l we have modernized the SECD machine 
into a stackless machine with a caller-save convention for environments, and then decon- 
structed the modernized version of this machine into a series of equivalent specifications, 
starting (essentially) from a relation between states and ending with an evaluation function. 
The diagram below graphically summarizes the deconstruction. The evaluators in the top 
row are the defunctionalized counterparts of the evaluators in the bottom row. (The ML 
code for evaluate2' ' and evaluate3' ' is not shown here.) 
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Using the tracing technique of Appendix[A] we can show that evaluate2' and evaluate2' ' 
operate in lockstep. We have however not proved this lockstep property for evaluate3' 
and evaluate3'' and for evaluated and evaluated ', satisfying ourselves with Plotkin's 
Simulation theorem [100], suitably extended for shift and reset [76,77]. 



3.6. On the J operator. We now reap the fruits of the modernization and the reconstruc- 
tion, and present a series of simulations of the J operator (Sections 13.6. 1| 13.6.21 and 13,6.3]) . 
We then put the J operator into perspective (Section I3.6.4p . 



3.6.1. Three simulations of the J operator. The evaluator of Section [3.41 (evaluate4 ' ') and 
the refunctionalized counterparts of the evaluators of Sections 13.21 and 13. II (evaluate3' ' and 
evaluate2 ' ' ) are compositional. They can be viewed as syntax-directed encodings into their 
meta-language, as embodied in the first Futamura projection [60] and the original approach 
to denotational semantics [112]. Below, we state these encodings as three simulations of J: 
one in direct style, one in CPS with one layer of continuations, and one in CPS with two 
layers of continuations. 

We assume a call-by-value meta-language with right-to-left evaluation. 
• In direct style, using shifty (S2), reset2 ((-)2), shift 1 (Si), and reseti ((-)i), based on the 
compositional evaluator evaluate4 ' ' in direct style: 



M 
H 
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[J] 
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M [ii] 
As.([t])i 
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A program p is translated as (([p])i)2- 

In CPS with one layer of continuations, using shift (S) and reset ((•)), based on the 
compositional evaluator evaluate3' ' in CPS with one layer of continuations: 

[re]' = Ac.c n 

lx}' = Ac.c x 
[to hf = Ac.pi]' Aui.[toF Xv .v Vl c 
IXx.tf = Ac.c Ax. Ac.c ({tf Xv.v) 



[J]' = Xc.SXd.d (c Xv.Xc.c Xv' .Xc' .SXd' .d (v v' Xv".v' r 



A program p is translated as ([p]' Xv.v). 

In CPS with two layers of continuations (the outer continuation, i.e., the dump continu- 
ation, can be 77-reduced in the first three clauses), based on the compositional evaluator 
evaluate2' ' in CPS with two layers of continuations: 

[nf = Xc.Xd.c n d 

\x\" = Xc.Xd.c x d 
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Analysis: The simulation of literals, variables, and applications is standard. The control 
continuation of the body of each A-abstraction is delimited, corresponding to it being eval- 
uated with an empty control stack in the SECD machine. The J operator abstracts the 
control continuation and the dump continuation and immediately restores them, resuming 
the computation with a state appender which holds the abstracted dump continuation cap- 
tive. Applying this state appender to a value v yields a program closure (boxed in the three 
simulations above). Applying this program closure to a value v' has the effect of discarding 
both the current control continuation and the current dump continuation, applying v to v', 
and resuming the captured dump continuation with the result. 

Assessment: The first rational deconstruction [35] already characterized the SECD machine 
in terms of the CPS hierarchy: the control stack is the first continuation, the dump is 
the second one (i.e., the meta-continuation) , and abstraction bodies are evaluated within 
a control delimiter (i.e., an empty control stack). Our work further characterizes the J 
operator as capturing (a copy of) the meta-continuation. 



3.6.2. The C operator and the CPS hierarchy. In the terminology of reflective towers [42], 
continuations captured with shift are "pushy" — at their point of invocation, they compose 
with the current continuation by "pushing" it on the meta-continuation. In the second 
encoding of J in Section [3.6.11 the term SXd'.d (v v' Xv".v") serves to discard the current 
continuation d' before applying the captured continuation d. Because of this use of shift to 
discard d', the continuation d is composed with the identity continuation. 

In contrast, still using the terminology of reflective towers, continuations captured with 
call/cc [29] or with Felleisen's C operator [50] are "jumpy" — at their point of invocation, 
they discard the current continuation. If the continuation d were captured with C, then the 
term d (v v' Xv".v") would suffice to discard the current continuation. 

The first encoding of J in Section 13.6.11 uses the pushy control operators S± (i.e., S) 
and £2- Murthy [94] and Kameyama [75] have investigated their jumpy counterparts in 
the CPS hierarchy, C\ (i.e., C) and CY Jumpy continuations therefore suggest two new 
simulations of the J operator. We show only the clauses for J, which are the only ones that 
change compared to Section [3.6.1l As before, we assume a call-by- value meta-language with 
right-to-left evaluation. 

• In direct style, using C2, reset2 ((-)2)> Ci, and reseti ((-)i): 



[J] = CiXc.C 2 Xd.d (c Xv.Xv'.d (v v') 1 



This simulation provides a new example of programming in the CPS hierarchy with jumpy 
delimited continuations. 

In CPS with one layer of continuations, using C and reset ((•)): 



[J]' = Xc.CXd.d (c Xv.Xc.c Xv'.Xc'.d (v v' Xv".v")) 



The corresponding CPS simulation of J with two layers of continuations coincides with the 
one in Section [3.6.11 
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3.6.3. The call/cc operator and the CPS hierarchy. Like shift and C, call/cc takes a snapshot 
of the current context. However, unlike shift and C, in so doing call/cc leaves the current 
context in place. So for example, 1 + (call/cc AA;.10) yields 11 because call/cc leaves the 
context 1 + [] in place, whereas both 1 + (SXk.10) and 1 + (CA/c.10) yield 10 because the 
context 1 + [ ] is tossed away. 

Therefore J can be simulated in CPS with one layer of continuations, using call/cc and 
exploiting its non-abortive behavior: 



[J]' = Ac.call/cc Xd.c \v.\c.c \\v'.\c'.d (v v' \v".v") 
The obvious generalization of call/cc to the CPS hierarchy does not work, however. One 
needs an abort operator as well in order for call/cc2 to capture the initial continuation and 
the current meta-continuation. We leave the rest of this train of thought to the imagination 
of the reader. 



3.6.4. On the design of control operators. We note that replacing C with S in Section T3.6.2I 
(resp. C\ with S\ and C2 with £2) yields a pushy counterpart for J, i.e., program closures 
returning to their point of activation. (Similarly, replacing C with S in the specification of 
call/cc in terms of C yields a pushy version of call/cc, assuming a global control delimiter.) 
One can also envision an abortive version of J that tosses away the context it abstracts. 
In that sense, control operators are easy to invent, though not always easy to implement 
efficiently. Nowadays, however, the litmus test for a new control operator lies elsewhere, for 
example: 

(1) Which programming idiom does this control operator reflect [29,38,41,102,108]? 

(2) What is the logical content of this control operator [66,97]? 

Even though it was the first control operator ever, J passes this litmus test. As pointed out 
by Thielecke, 

(1) besides reflecting Algol jumps and labels [81], J provides a generalized return [115, 
Section 2.1], and 

(2) the type of J Xv.v is the law of the excluded middle [116, Section 5.2]. 

On the other hand, despite their remarkable fit to Algol labels and jumps (as illustrated 
in the beginning of Section [1]), the state appenders denoted by J are unintuitive to use. 
For example, if a let expression is the syntactic sugar of a beta-redex (and x\ is fresh), the 
observational equivalence 

to t\ = let x\ = t\ in to x\ 
does not hold in the presence of J due to the non-standard translation of abstractions, even 
though it does hold in the presence of call/cc, C, and shift for right-to-left evaluation. For 
example, given C[] = (\x2succ []) 10, to = J (Xk.k) 0, and t\ = 100, C[to ti] yields 
whereas C[let x\ = t\ in to x\] yields 1. 
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4. DECONSTRUCTION OF THE SECD MACHINE WITH THE J OPERATOR: 

CALLER-SAVE DUMPS 

In Section [3j we modernized the SECD machine by removing the intermediate data 
stack and by managing the environment in a caller-save rather than callee-save fashion. 
We left the 'non-modern' feature of the dump continuation alone because it was part of 
the SECD-machine semantics of the J operator. In this section, we turn our attention to 
this dump continuation, and we identify that like the environment in the original SECD 
machine, the dump continuation is managed in a callee-save fashion. Indeed the apply 
function receives a dump continuation from its caller and passes it in turn to the control 
continuation. 



4.1. A specification with caller-save dump continuations. Let us modernize the 
SECD machine further by managing dump continuation in a caller-save fashion. Our rea- 
soning is similar to that used in Section [3] for the environment. Inspecting the evaluator 
evaluate2' shows that when either eval or apply receives a control continuation c and a 
dump continuation d as arguments and applies c, the dump continuation d is passed to c. 
Therefore, when the control continuation passed to eval or apply is fn (v, d) => d v and 
the dump continuation is some d', d' can be substituted for d in the body of the control 
continuation. After this change, inspecting the control continuations reveals that the ones 
created in apply and evaluate2' ignore their dump-continuation arguments, and the ones 
created in eval are passed a dump continuation that is already in their lexical scope. There- 
fore, the control continuations do not need to be passed a dump continuation. Since the 
dump continuation was passed to apply solely for the purpose of threading it to the control 
continuation, apply does not need to be passed a dump continuation either. 

The evaluator of Section [3.11 with caller-save dump continuations reads as follows: 

datatype value = INT of int 
I SUCC 

I FUNCLO of E * string * term 

I STATE_APPENDER of D 

I PGMCLO of value * D 
withtype E = value Env . env 
and D = value -> value 
and C = value -> value 



val 

(* 
(* 



e_init 
eval : 
apply : 



Env. extend ("succ", SUCC, Env. empty) 



term * E * C * D -> value 
value * value * C -> value 
d) 



(* environment *) 
(* dump continuation *) 
(* control continuation *) 

*) 
*) 



fun eval (LIT n, e, c, 
= c (INT n) 
I eval (VAR x, e, c, d) 

= c (Env. lookup (x, e)) 
I eval (LAM (x, t) , e, c, d) 

= c (FUNCLO (e, x, t)) 
I eval (APP (tO, tl) , e, c, d) 
= eval (tl, e, fn vl => 
eval (tO, e, fn vO => 

apply (vO, vl, c) , d) , d) 
I eval (J, e, c, d) 

= c ( STATE_ APPENDER d) 
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and apply (SUCC, INT n, c) 

= c (INT (n + 1)) 
I apply (FUNCLO (e', x, t) , v, c) 

= eval (t, Env. extend (x, v, e'), c, c) 
I apply (STATE_APPENDER d' , v, c) 

= c (PGMCLO (v, d')) 
I apply (PGMCLO (v, d'), V, c) 

= apply (v, v' , d' ) 

fun evaluate2 ' _alt t (* evaluate2 ' _alt : program -> value *) 

= eval (t, e_init, fn v => v, fn v => v) 

This evaluator still passes two continuations to eval. However, the dump continuation is 
no longer passed as an argument to the control continuation. Thus, the two continuations 
have the same type. The dump continuation is a snapshot of the control continuation of the 
caller. It is reset to be the continuation of the caller when evaluating the body of a function 
closure and it is captured in a state appender by the J operator. Applying a program closure 
discards the current control continuation in favor of the captured dump continuation. 

As in Section 13. H the abstract machine corresponding to evaluate2 ' _alt (obtained 
by defunctionalization and displayed in Section [HJ) operates in lockstep with the abstract 
machine corresponding to evaluate2' (obtained by defunctionalization and displayed in 
Section [7]). The following proposition is a corollary of this bisimulation and the correctness 
of defunctionalization: 

Proposition 4.1 (full correctness). Given a program, evaluate2' and evaluate2'^alt either 
both diverge or both yield values; and if these values have an integer type, they are the same 
integer. 

4.2. The rest of the rational deconstruction. The evaluator of Section 14.11 can be 
transformed exactly as the higher-order evaluators of Sections 12.21 and 13.11 

(1) A direct-style transformation with respect to the control continuation yields an 
evaluator in direct style. 

(2) Refunctionalizing the applicable values yields a compositional, higher-order evalua- 
tor in direct style. 

Graphically: 



evaluatel 

A 



defunctionalization 
of the continuations 



evaluate 2 



bisimulation 



'modernization': 

a caller-save dump continuation 



Y 

evaluatel ' ^alt 



¥ 

evaluate2 ' _alt 



evaluate3 ' _alt 



direct-style transformation 
wrt. 

the control continuation 



evaluate 2 ' _alt ' 



refunctionalization 
of the applicable values 



evaluate3 ' _alt ' 
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4.3. Two other simulations of the J operator. As in Section [3.6.11 the compositional 
evaluators of Section 14.21 can be viewed as syntax-directed translations into their meta- 
language. Below, we state these encodings as two further simulations of the J operator: 
one in CPS with an additional return continuation, and one in direct-style with a return 
continuation. 

• In CPS with an additional return continuation, based on evaluate3'_alt: 



H' 


= Xc.Xd.c n 






M 


= Xc.Xd.c x 






Po hf 


= Xc.Xd.lhf (XvLltof 


{Xvq.Vq Vi 


c) d) d 


IXx.tf 


= Xc.Xd.c Xv .Ac. pi 


' cc 




[J]' 


= Xc.Xd.c Xvq.Xc.c 


Xv\ 


Xc.vq v\ d 





A program p is translated as Ipf (Xv.v) Xv.v. 

In direct style with a return continuation, based on evaluate3'_alt': 

[n] = Xd.n 

[x] = Xd.x 
po *ij = Ad. p ]d (pi] d) 
IXx.tj = Xd.Xx.SXc.{c (p] c)) 



[J] = Xd.XvQ. Xv \.SXc.{d (vq v\)} 



A program p is translated as ([p] Xv.v). 

NB. Operationally, the two occurrences of reset surrounding the body of the shift- 
expression are unnecessary. They could be omitted. 



Assessment: Transformed terms are passed a pair of continuations, the usual continuation 
of the call-by-value CPS transform and a return continuation. Abstractions set the return 
continuation to be the continuation at their point of invocation, i.e., the continuation of 
their caller. The J operator captures the current return continuation in a program closure 
(boxed above). 



4.4. Thielecke. In his work on comparing control constructs [116], Thielecke introduced 
a 'double-barrelled' CPS transformation, where terms are passed an additional 'jump con- 
tinuation' in addition to the usual continuation of the call-by-value CPS transformation. 
By varying the transformation of abstractions, he was able to account for first-class con- 
tinuations, exceptions, and jumping. His double-barrelled CPS transformation, including a 
clause for his JI operator (i.e., J Xx.x) and modified for right-to-left evaluation, reads as 
follows: 

[x] = Xc.Xd.c x 

po hj = Ac.Ad.pl] (Aui.pol (^o-vo V! cd)d)d 

IXx.tj = Xc.Xd.c Xx. Ac'. Ad'. pj c' c' 
[JI] = Ac.Ad.c Xx.Xc'.Xd'.d x 
The continuation c is the continuation of the usual call-by-value CPS transformation. The 
continuation d is a return continuation, i.e., a snapshot of the continuation of the caller of 
a function abstraction. It is set to be the continuation of the caller in the body of each 
function abstraction and it is captured as a first-class function by the JI operator. The extra 
continuation passed to each abstraction is not necessary (for the encoding of JI), and can be 
eliminated from the translation of abstractions and applications, as we did in Section f4.il 



21 



O. DANVY AND K. MILLIKIN 



As noted by Thielecke and earlier Landin, J can be expressed in terms of JI as: 

J = (Xc.Xv.Xv'.c (v v')) (JI) 

The /3-expansion is necessary to move the occurrence of JI outside of the outer abstraction, 
because A-abstractions are CPS-transformed in a non-standard way. By CPS-transforming 
this definition and eliminating the extra continuation for function abstractions, we derive 
the same double-barrelled encoding of Landin's J operator as in Section 14,31 

\xf = Xc.Xd.c x 
[i hf = Xc.Xd.lhf (Aui.poJ' (Xv Q .v Vl c) d) d 
IXx.tj' = Xc.Xd.c Xx.Xc'.ltf d d 

[J]' = Ac.Ad.c Xv.Xd.d 



Xv'.Xd'.v v' d 



Analysis: In essence, Thielecke's simulation corresponds to an abstract machine which is 
the caller-save counterpart of Landin's machine with respect to the dump. 



4.5. Felleisen. Felleisen showed how to embed Landin's extension of applicative expres- 
sions with J into the Scheme programming language [51]. The embedding is defined using 
Scheme syntactic extensions (i.e., macros). J is treated as a dynamic identifier that is 
bound in the body of every abstraction, similarly to the dynamically bound identifier 'self 
in an embedding of Smalltalk into Scheme [84]. The control aspect of J is handled through 
Scheme's control operator call/cc. 

Here are the corresponding simulations: 
• In direct style, using either of call/cc, C, or shift (S), and a control delimiter ((•)): 

H = x 



Ito hj 

IXx.tj 



Xx.CXd.let J 
Ax.iSAd.let J 



Xv 
Xv 



= Xv. 


Xv'.d (v v') 


Xv'.d (v v') 


ind \i 


Xv'.SXc'.d (v v') i 



A program p is translated as let J = Xv .Xv' .(v v') in ([p]). 
In CPS: 

{xf = Xc.c x 
lt hf = Xc.lhf XvLltof Xvq.Vq Vl c 



Xv'.Xc'.v v' d 



in 



I'd) 



\Xx.tf = Xc.c (Xx.Xd.let J = Xv .Xc.c 
A program p is translated as let J = Xv.Xc.c (Xv' .Xd .v v' Xv" .v") in Xv.v. 

Analysis: The simulation of variables and applications is standard. The continuation of 
the body of each A-abstraction is captured, and the identifier J is dynamically bound to a 
function closure (the state appender) which holds the continuation captive. Applying this 
function closure to a value v yields a program closure (boxed in the simulations above). 
Applying this program closure to a value v' has the effect of applying v to v' and resuming 
the captured continuation with the result, abandoning the current continuation. 

The evaluator corresponding to these simulations always has a binding of J in the envi- 
ronment when evaluating the body of an abstraction (see Section [TOl) . Under the assumption 
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that J is never shadowed in a program, passing this value as a separate argument to the 
evaluator leads one towards the definition of evaluate2'_alt in Section [4.11 (see Section [9|). 

5. Related work 

5.1. Landin and Burge. Landin [82] introduced the J operator as a new language feature 
motivated by three questions about labels and jumps: 

• Can a language have jumps without having assignments? 

• Is there some component of jumping that is independent of labels? 

• Is there some feature that corresponds to functions with arguments in the same sense 
that labels correspond to procedures without arguments? 

Landin gave the semantics of the J operator by extending the SECD machine. In addition 
to using J to model jumps in Algol 60 [81], he gave examples of programming with the J 
operator, using it to represent failure actions as program closures where it is essential that 
they abandon the context of their application. 

In his textbook [21, Section 2.10], Burge adjusted Landin's original specification of the 
J operator. Indeed, in Landin's extension of the SECD machine, J could only occur in the 
context of an application. Burge adjusted the original specification so that J could occur 
in arbitrary contexts. To this end, he introduced the notion of a "state appender" as the 
denotation of J. 

Thielecke [115] gave a detailed introduction to the J operator as presented by Landin 
and Burge. Burstall [22] illustrated the use of the J operator by simulating threads for 
parallel search algorithms, which in retrospect is the first simulation of threads in terms of 
first-class continuations ever. 

5.2. Reynolds. Reynolds [102] gave a comparison of J to escape, the binder form of 
Scheme's call/cc [29] Q He gave encodings of Landin's J (i.e., restricted to the context 
of an application) and escape in terms of each other. 

His encoding of escape in terms of J reads as follows: 

(escape k in t)* = let k = 3 Xv.v in t* 

As Thielecke notes [115], this encoding is only valid immediately inside an abstraction. 
Indeed, the dump continuation captured by J only coincides with the continuation captured 
by escape if the control continuation is the initial one (i.e., immediately inside a control 
delimiter). Thielecke therefore generalized the encoding by adding a dummy abstraction: 

(escape k in t)* = (AQ.let k = 3 Xx.x int*) Q 

From the point of view of the rational deconstruction of Section [3l this dummy abstraction 
implicitly inserts a control delimiter. 

Reynolds's converse encoding of J in terms of escape reads as follows: 

(let d = 3 Xx.ti in io)° = escape k in (let d = Xx.k ti° in to°) 



escape k in t 



= call/cc Xk.t 
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where k does not occur free in to and t\. For the same reason as above, this encoding is 
only valid immediately inside an abstraction and therefore it can be generalized by adding 
a dummy abstraction: 

(let d = J \x.t\ in to)° = (A(). escape k in (let d = Xx.k t\° in to )) () 

5.3. Felleisen and Burge. Felleisen's version of the SECD machine with the J operator 
differs from Burge's. In the notation of Section 11.51 Burge's clause for applying program 
closures reads 

I run ((PGMCLO (v, (s', e', c>) :: d')) :: V :: s, e, APPLY : : c , d) 
= run (v :: v' :: s', e', APPLY :: c', d') 

instead of 

I run ((PGMCLO (v, d')) :: V :: s, e, APPLY :: c, d) 
= run (v : : v' :: nil, e_init, APPLY :: nil, d') 

Felleisen's version delays the consumption of the dump until the function, in the program 
closure, completes, whereas Burge's version does not. The modification is unobservable 
because a program cannot capture the control continuation and because applying the ar- 
gument of a state appender pushes the data stack, the environment, and the control stack 
on the dump. Felleisen's modification can be characterized as wrapping a control delimiter 
around the argument of a dump continuation, similarly to the simulation of static delimited 
continuations in terms of dynamic ones [18]. 

Burge's version, however, is not in defunctionalized form. In Section [U we put it in 
defunctionalized form without resorting to a control delimiter and we outline the corre- 
sponding compositional evaluation functions and simulations. 

6. DECONSTRUCTION OF THE ORIGINAL SECD MACHINE WITH THE J OPERATOR 

We now outline the deconstruction of Burge's specification of the SECD machine with 
the J operator. 

6.1. Our starting point: Burge's specification. As pointed out in Section 15.31 Fell- 
eisen's version of the SECD machine applies the value contained in a program closure before 
restoring the components of the captured dump. Burge's version differs by restoring the 
components of the captured dump before applying the value contained in the program 
closure. In other words, 

• Felleisen's version applies the value contained in a program closure with an empty data 
stack, a dummy environment, an empty control stack, and the captured dump, whereas 

• Burge's version applies the value contained in a program closure with the captured data 
stack, environment, control stack, and previous dump. 

The versions induce a minor programming difference because the first makes it possible to 
use J in any context whereas the second restricts J to occur only inside a A-abstr action. 

Burge's specification of the SECD machine with J follows. Ellipses mark what does not 
change from the specification of Section II. 5t 
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(* run : S*E*C*D-> value *) 
fun run (v :: nil, e, nil, d) 

run (s, e, (TERM t) : : c, d) 

run (SUCC :: (INT n) :: s, e, APPLY :: c, d) 

run ((FUNCLO (e\ x, t)) :: v :: s, e, APPLY :: c, d) 

run ( (STATE_APPENDER d') :: v :: s, e, APPLY :: c, d) 

run ( (PGMCLQ (v, (s', e', c>) :: d')) :: V :: s, e, APPLY :: c, d) 
= run (v :: v' :: s', e', APPLY :: c', d') 
fun evaluateO_alt t (* evaluateO_alt : program -> value *) 

Just as in Section \2. 11 Burge's specification can be disentangled into four mutually-recursive 
transition functions. The disentangled specification, however, is not in defunctionalized 
form. We put it next in defunctionalized form without resorting to a control delimiter, and 
then outline the rest of the rational deconstruction. 



6.2. Burge's specification in defunctionalized form. The disentangled specification 
of Burge is not in defunctionalized form because the dump does not have a single point of 
consumption. It is consumed by run_d for values yielded by the body of A-abstractions and 
in run_a for values thrown to program closures. In order to be in the image of defunctional- 
ization and have run_d as the apply function, the dump should be solely consumed by run_d. 
We therefore distinguish values yielded by normal evaluation and values thrown to program 
closures, and we make run_d dispatch over these two kinds of returned values. For values 
yielded by normal evaluation (i.e., in the call from run_c to run_d), run_d proceeds as before. 
For values thrown to program closures, run_d calls run_a. Our modification therefore adds 
one transition (from run_a to run_d) for values thrown to program closures. 

The change only concerns three clauses and ellipses mark what does not change from 
the evaluator of Section 12.11 

datatype returned_value = YIELD of value 

I THROW of 

(* run_c : S * E * 

(* run_d : returned_val 

(* run_t : term * S * E * 

(* run_a : value * value * S * E * 

fun run_c (v :: nil, e, nil, d) 
= run_d (YIELD v, d) 
I run_c . . . 

and run_d (YIELD v, nil) 
= v 

I run_d (YIELD v, (s, e, c) :: d) 

= run_c (v :: s, e, c, d) 
I run_d (THROW (v, v'), (s, e, c) 

= run_a (v, v' , s, e, c, d) 



value * value 

C * D -> value *) 

.ue * D -> value *) 

C * D -> value *) 

C * D -> value *) 

(* 1 *) 



d) 



(* 2 *) 
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and run_t . . . 

and run_a . . . 

I run_a (PGMCLO (v, d'), V, s, e, c, d) 

= run_d (THROW (v, v'), d') (* 3 *) 

fun evaluatel_alt t (* evaluatel_alt : program -> value *) 

YIELD is used to tag values returned by function closures (in the clause marked "1" above), 
and THROW is used to tag values sent to program closures (in the clause marked "3"). THROW 
tags a pair of values, which will be applied in run_d (by calling run_a in the clause marked 
"2"). 

Proposition 6.1 (full correctness). Given a program, evaluateCLalt and evaluatel_alt 

either both diverge or both yield values that are structurally equal. 



6.3. A higher-order counterpart. In the modified specification of Section [6.21 the data 
types of control stacks and dumps are identical to those of the disentangled machine of 
Section 12.11 These data types, together with run_d and run_c, are in the image of defunc- 
tionalization (run_d and run_c are their apply functions). The corresponding higher-order 
evaluator reads as follows: 

datatype value = INT of int 
I SUCC 

I FUNCLO of E * string * term 
I STATE_APPENDER of D 
I PGMCLO of value * D 
and returned_value = YIELD of value 

I THROW of value * value 
withtype S = value list (* data stack *) 

and E = value Env.env (* environment *) 

and D = returned_value -> value (* dump continuation *) 

and C=S*E*D-> value (* control continuation *) 

val e_init = Env. extend ("succ", SUCC, Env. empty) 

(* run_t : term *S*E*C*D-> value *) 

(* run_a : value * value *S*E*C*D-> value *) 
(* where S = value list, E = value Env.env, C = S*E*D-> value *) 
(* and D = returned_value -> value *) 
fun run_t . . . 

and run_a (SUCC, INT n, s, e, c, d) 
= c ((INT (n+D) : : s, e, d) 
I run_a (FUNCLO (e', x, t) , v, s, e, c, d) 
= run_t (t, nil, Env. extend (x, v, e'), 

fn (v : : nil, e, d) => d (YIELD v) , 
fn (YIELD v) 

=> c (v : : s , e , d) 
I (THROW (f, v)) 
=> run_a (f, v, s, e, c, d) ) 
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I run_a (STATE_APPENDER d' , v, s, e, c, d) 

= c ((PGMCLO (v, d')) :: s, e, d) 
I run_a (PGMCLO (v, d'), V, s, e, c, d) 
= d' (THROW (v, v')) 
fun evaluate2_alt t (* evaluate2_alt : program -> value *) 

= run_t (t, nil, e_init, fn (v :: nil, e, d) => d (YIELD v) , 
fn (YIELD v) => v) 

As before, the resulting evaluator is in continuation-passing style (CPS), with two layered 
continuations. It threads a stack of intermediate results, a (callee-save) environment, a 
control continuation, and a dump continuation. The values sent to dump continuations are 
tagged to indicate whether they represent the result of a function closure or an application 
of a program closure. Defunctionalizing this evaluator yields the definition of Section 16. 2\ 

Proposition 6.2 (full correctness). Given a program, evaluatel_alt and evaluate2_alt 

either both diverge or yield expressible values; and if these values have an integer type, they 
are the same integer. 

6.4. The rest of the rational deconstruction. The evaluator of Section 16.31 can be 
transformed exactly as the higher-order evaluator of Section 12.21 

(1) Eliminating the data stack and the callee-save environment yields a traditional eval- 
apply evaluator, with run_t as eval and run_a as apply. The evaluator is in CPS with 
two layers of continuations. 

(2) A first direct-style transformation with respect to the dump yields an evaluator that 
uses shift and reset (or C and a global reset, or again call/cc and a global reset) to 
manipulate the implicit dump continuation. 

(3) A second direct-style transformation with respect to the control stack yields an 
evaluator in direct style that uses the delimited-control operators shifti, reseti, 
shift2, and reset2 (or C±, reseti, C2, and reset2) to manipulate the implicit control 
and dump continuations. 

(4) Refunctionalizing the applicable values yields a compositional, higher-order, direct- 
style evaluator corresponding to Burge's specification of the J operator. The result 
is presented syntax-directed encoding next. 

6.5. Three simulations of the J operator. As in Section [lOTH the compositional coun- 
terpart of the evaluators of Section 16.41 can be viewed as syntax-directed encodings into 
their meta-language. Below, we state these encodings as three simulations of J: one in 
direct style, one in CPS with one layer of continuations, and one in CPS with two layers of 
continuations. Again, we assume a call-by- value meta-language with right-to-left evaluation 
and with a sum (to distinguish values returned by functions and values sent to program clo- 
sures), a case expression (for the body of A-abstractions) and a destructuring let expression 
(at the top level). 
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In direct style, using either of shifty, reset2, shift i, and reseti or C2, reset2, C\, and reset 1, 
based on the compositional evaluator in direct style: 



M 

Po *il 
{Xx.tJ 



n 

x 

Po] Pi] 

Ax. case (inLp])i 
of inL(v) v 
I inR(c, v') 
S\Xc.S2\d.d (c Xv 
CiXc.C^Xd.d (c Xv. 



V V 



Xv' .Si Ac' .S 2 Xd' .d (inR(u,T/)) 



Au'.d (inR(u, v')) ) 



A program p is translated as (let inL(u) = (inL([p]))i in v)2- 

In CPS with one layer of continuations, using either of shift and reset, C and reset, 
or call/cc and reset, based on the compositional evaluator in CPS with one layer of 
continuations: 

- Ac.c n 



in 



Po hf 

IXx.tf 



Xc.c x 

Ac.pi]' (Awi.po]' M)-«o c) 
Ac.c (Ax.Ac.case p]' Xv.inL(v) 
of inL(v) cv 
I inR(f , v') => v v' c) 



[J]' 



Av'.Ac'.SAd'.d (inR(w,r/)) 



At/.Ac'.d (iiiR^.u'))) 



Xc.SXd.d (c Ac. Ac.c 
= Xc.CXd.d (c Ac. Ac.c 

= Ac.call/cc Ad.c Ac. Ac.c Xv'.Xc'.d (inR(c,c')) 
A program p is translated as (let inL(c) = [p]' Ac.inL(c) inc). 

In CPS with two layers of continuations, based on the compositional evaluator in CPS 
with two layers of continuations: 

H" = Ac.Ad.c n d 
\x\" = Xc.Xd.c x d 
po hj" = Ac.Ad.pi]" (Awi.Ad.pof (Ac .Ad.c Vl cd) d) d 

IXx.tj" = Xc.Xd.c (Xx.Xc.Xd.ltf (Xv.Xd.d (inL(u))) 

At>". case v" 

of inL(c) c c d 
I inR(c, v') =4> v v' c d) d 

m" 



Xc.Xd.c (Xv. Ac. Ad'". c ( Xv'. Ac'. Ad'. d (inR(v,i/))) d'") d 



A program p is translated as [p]" (Xv.Xd.d (ihL(v))) (Ac. let inL(c') = c in?/). 

Analysis: The simulation of literals, variables, and applications is standard. The body of 
each A-abstraction is evaluated with a control continuation injecting the resulting value into 
the sum typ^ to indicate normal completion and resuming the current dump continuation, 
and with a dump continuation inspecting the resulting sum to determine whether to con- 
tinue normally or to apply a program closure. Continuing normally consists of invoking 



This machine is therefore not properly tail recursive. 
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the control continuation with the resulting value and the dump continuation. Applying a 
program closure consists of restoring the components of the dump and then performing the 
application. The J operator abstracts both the control continuation and the dump contin- 
uation and immediately restores them, resuming the computation with a state appender 
holding the abstracted dump continuation captive. Applying this state appender to a value 
v yields a program closure (boxed in the three simulations above). Applying this program 
closure to a value v' has the effect of discarding both the current control continuation and 
the current dump continuation, injecting v and v ' into the sum type to indicate exceptional 
completion, and resuming the captured dump continuation. It is an error to evaluate J 
outside of a A-abstraction. 

6.6. Related work. Kiselyov's encoding of dynamic delimited continuations in terms of 
the static delimited-continuation operators shift and reset [78] is similar to this alternative 
encoding of the J operator in that both encodings tag the argument to the meta-continuation 
to indicate whether it represents a normal return or a value thrown to a first-class contin- 
uation. In addition though, Kiselyov uses a recursive meta-continuation in order to encode 
dynamic delimited continuations. 

7. A SYNTACTIC THEORY OF APPLICATIVE EXPRESSIONS WITH THE J OPERATOR: 

EXPLICIT, CALLEE-SAVE DUMPS 

Symmetrically to the functional correspondence between evaluation functions and ab- 
stract machines that was sparked by the first rational deconstruction of the SECD ma- 
chine [3,4,6,7,13,16,35,36], a syntactic correspondence exists between calculi and abstract 
machines, as investigated by Biernacka, Danvy, and Nielsen [12,14,15,34,36,45]. This 
syntactic correspondence is also derivational, and hinges not on defunctionalization but on 
a 'refocusing' transformation that mechanically connects an evaluation function defined as 
the iteration of one-step reduction, and an abstract machine. 

The goal of this section is to present the reduction semantics and the reduction-based 
evaluation function that correspond to the modernized SECD machine of Section 13.11 We 
successively present this machine (Section 17. ID . the syntactic correspondence (Section 17.21) . 
a reduction semantics for applicative expressions with the J operator (Section IT.3[) . and the 
derivation from this reduction semantics to this SECD machine (Section I7.4h . We consider 
a calculus of explicit substitutions because the explicit substitutions directly correspond 
to the environments of the modernized SECD machine. In turn, this calculus of explicit 
substitutions directly corresponds to a calculus with actual substitutions. 

7.1. The SECD machine with no data stack and caller-save environments, revis- 
ited. The terms, values, environments, and contexts are defined as in Section [1.51 



(programs) 


p : 


:= t[(succ, SUCC) ■ 0} 


(terms) 


t : 


:= V 


x Xx.t | tt | J 


(values) 


v : 


:= V 


SUCC | (Xx.t,e) 


(environments) 


e : 


:= 


(x, v) ■ e 


(control contexts) 


C : 


■= U 1 


C[(t,e)[]] | C[[]v] 


(dump contexts) 


D : 


:= • | 


C-D 
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The following four transition functions are the stackless, caller-save respective counterparts 
of run_t, run_a, run.c, and run_d in Section [270 This abstract machine is implemented by the 
modernized and disentangled evaluator evaluate!' in the diagram at the end of Section \3. II 



(V, e, C, D) cval 
(x, e, C, -D) eval 
(Xx.t, e, C, D) cval 
(t h, e, C, D) cval 
(J, e, C, D) cval 

(SUCC, V, C, D) apply 
((Xx.t,e),v, C, D) apply 
(T/W, v, C, D) apply 
(T^, v, C, D) apply 

([]>*>> D )cont 

(C[(t,e) [}},v, D) cont 
(C[[]v'],v, D) coQt 

\ m i U )dump 
( C ■ D i U )dump 



(C, V, D) COQt 

(C ; w > ^)cont 

(C, (Xx.t,e),D) cont 
(h,e, C[(t ,e)[]],D) cval 

(c, r rr, D) cont 

(C, r„ + V, D) CQQt 
(t, e>, [},C-D) cval 
(v, v', [],D') apply 
(C, r D n o „, D) cont 

(-^i U )dump 

(t, e, C[[]v],D) cval 

<«. ^> C, -D) apply 



if lookup(x, e) 



(C, v, D) 



cont 



where e' = extend(x, v, e) 



A program t is evaluated by starting in the configuration (t, (succ, SUCC) ■ 0, 
The machine halts with a value v if it reaches a configuration (•, w) dump . 



/ cval ' 



7.2. From reduction semantics to abstract machine. Consider a calculus together 
with a reduction strategy expressed as a Felleisen-style reduction semantics satisfying the 
unique-decomposition property [50]. In such a reduction semantics, a one-step reduction 
function is defined as the composition of three functions: 

decomposition: a total function mapping a value term to itself and decomposing a 
non-value term into a potential redex and a reduction context (decomposition is a 
function because of the unique-decomposition property); 
contraction: a partial function mapping an actual redex to its contractum; and 
plugging: a total function mapping a term and a reduction context to a new term by 
filling the hole in the context with the term. 
The one-step reduction function is partial because it is the composition of two total functions 
and a partial function. 

An evaluation function is traditionally defined as the iteration of the one-step reduction 
function: 



reduction step reduction step 
o >- o >- o 




O s- O O s- O O s- 

contract contract contract 
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Danvy and Nielsen have observed that composing the two total functions plug and decom- 
pose into a 'refocus' function could avoid the construction of intermediate terms: 




— — — ;»- O 5>- o — — — — — — — >-o >- o — — — — — — — »-o s- 

contract refocus contract refocus contract 

The resulting 'refocused' evaluation function is defined as the iteration of refocusing and 
contraction. CPS transformation and defunctionalization make it take the form of a state- 
transition function, i.e., an abstract machine. Short-circuiting its intermediate transitions 
yields abstract machines that are often independently known [45]. 

Biernacka and Danvy then showed that the refocusing technique could be applied to 
the very first calculus of explicit substitutions, Curien's simple calculus of closures [31], 
and that depending on the reduction order, it gave rise to a collection of both known 
and new environment-based abstract machines such as Felleisen et al.'s CEK machine (for 
left-to-right applicative order), the Krivine machine (for normal order), Krivine's machine 
(for normal order with generalized reduction), and Leroy's ZINC machine (for right-to- left 
applicative order with generalized reduction) [14]. They then turned to context-sensitive 
contraction functions, as first proposed by Felleisen [50], and showed that refocusing me- 
chanically gives rise to an even larger collection of both known and new environment-based 
abstract machines for languages with computational effects such as Krivine's machine with 
call/cc, the A/U-calculus, static and dynamic delimited continuations, input/output, stack 
inspection, proper tail-recursion, and lazy evaluation [15]. 

The next section presents the calculus of closures corresponding to the abstract machine 
of Section 17.11 

7.3. A reduction semantics for applicative expressions with the J operator. The 

ApJ-calculus is an extension of Biernacka and Danvy's Ap-calculus [14], which is itself 
a minimal extension of Curien's original calculus of closures \p [31] to make it closed 
under one-step reduction. We use it here to formalize Landin's applicative expressions with 
the J operator as a reduction semantics. To this end, we present its syntactic categories 
(Section 17. 3. ip ; a plug function mapping a closure and a two-layered reduction context into 
a closure by filling the given context with the given closure (Section 17. 3. 2j) ; a contraction 
function implementing a context-sensitive notion of reduction (Section I7.3.3P and therefore 
mapping a potential redex and its reduction context into a contractum and a reduction 
context (possibly another one); and a decomposition function mapping a non- value term 
into a potential redex and a reduction context (Section I7.3.4[) . We are then in position 
to define a one-step reduction function (Section 17.3. 5p . and a reduction-based evaluation 
function (Section I7.3.6j) . 

Before delving into this section, the reader might want to first browse through Section [El 
in the appendix. This section has the same structure as the present one but instead of the 
SECD machine, it addresses the CEK machine, which is simpler. 
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7.3.1. Syntactic categories. We consider a variant of the ApJ-calculus with names instead 
of de Bruijn indices, and with two layers of contexts C and D that embody the right-to-left 
applicative-order reduction strategy favored by Landin: C is the control context and D 
is the dump context. In the syntactic category of closures, r LP and r LP o v respectively 
denote a state appender and a program closure, and (c) (which is shaded below) marks the 
boundary between the context of a /3-redex that has been contracted, i.e., a function closure 
that has been applied, and the body of the A-abstraction in this function closure: 



(programs) 


p : 


:= t[(succ, SUCC) ■ 0] 


(terms) 


t : 


■= r n~ l x Xx.t \ 1 1 \ J 


(closures) 


c : 


:= r n? SUCC \ t[e] | c c | HEP | r D n o v 


(values) 


v : 


:= r rP SUCC {Xx.t)[e} | r _D n | r LP o v 


(potential redexes) 


r : 


:= x[e] \ v v | J 


(substitutions) 


e : 


:= (x, v) ■ e 


(control contexts) 


C : 


■■=[] 1 C[c[]] | C[[]v] 


(dump contexts) 


D : 


:= • | C-D 



Values are therefore a syntactic subcategory of closures, and in this section, we make use 
of the syntactic coercion j mapping a value into a closure. 



7.3.2. Plugging. Plugging a closure in the two layered contexts is defined by induction 
over these two contexts. We express this definition as a state-transition system with two 
intermediate states, (C, c, £>) p i U g/ CO nt and (D, c) plug/dump , an initial state (C, c, D) plng/cont , 
and a final state c. The transition function from the state (C, c, -D) p i U g/cont incrementally 
peels off the given control context and the transition function from the state (D, c) p i U g^(j ump 
dispatches over the given dump context: 

([]) -^)plug/cont * v^J W plug/dump 
(C[cq []], Ci, -D)pl U g/ C ont {C, C Ci, 

-^)plug/cont 

(C[[ } ui], c , £>)piug/ CO nt -> (C, c ci, D) phlg/cont where ci = | «i 

(*> ^) plug/dump ^ C 
(C • D, c) plug/dump ~~ > ((c), C, -D)plug/cont 

We can now define a total function plug over closures, control contexts, and dump 
contexts that fills the given closure into the given control context, and further fills the 
result into the given dump context: 

plug : Closure x Control x Dump — > Closure 

Definition 7.1. For any closure c, control context C, and dump context D, plug (C, c, D) = 
d if and only if (C, c, £>) p i ug / cont ^* d. 



7.3.3. Notion of contraction. The notion of reduction over applicative expressions with the J 
operator is specified by the following context-sensitive contraction rules over actual redexes: 



(Var) (x[e], C, D) t— > {v, C, D) if lookup(x,e) = v 
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(Beta succ ) {SUCC V, C, D) ^ ( r n + V, C, D) 

(Betake*) (((Xx.t)[e\) v, C, D) \— > (t[e'], [], C ■ D) where e' = extend(x, v, e) = (x,v) • e 
(Beta SA ) ( r D n v, C, D) ^ ( r D n o v, C, D) 

(Betapc) {{ r D n a v') v, C, D) ^ (v' v, [], D') 

(Prop) ((t h)[e], C, D) ^ ((t [e]) (*i[e]), C, £>) 
(J) (J, C, D) ^ ( r ^, C, D) 



Three of these contraction rules depend on the contexts: the J rule captures a copy of the 
dump context and yields a state appender; the /3-rule for function closures resets the control 
context and pushes it on the dump context; and the /3-rule for program closures resets the 
control context and reinstates a previously captured copy of the dump context. 

Among the potential redexes, only the ones listed above are actual ones. The other 
applications of one value to another are stuck. 

We now can define by partial function contract over potential redexes that 

contracts an actual redex and its two layers of contexts into the corresponding contractum 
and contexts: 



Definition 7.2. For any potential redex r, control context C, and dump context D, 
contract (r, C, D) = (c, C, D') if and only if (r, C, D) ^ (c, C", D'). 



7.3.4. Decomposition. There are many ways to define a total function mapping a value 
closure to itself and a non- value closure to a potential redex and a reduction context. In 
our experience, the following definition is a convenient one. It is a state-transition system 
with three intermediate states, (c, C, D) dcc/clos , (C, v, D) dcc/cont , and (D, v) dcc/dnmp , an 
initial state (c, [], •)doc/cios an d two final states VAL (v) and DEC (r, C, D). If possible, 
the transition function from the state (c, C, D) dcc / c i os decomposes the given closure c and 
accumulates the corresponding two layers of reduction context, C and D. The transition 
function from the state (C, v, D) dec / cont dispatches over the given control context, and the 
transition function from the state (D, v) dcc / dump dispatches over the given dump context. 



contract : PotRed x Control x Dump — Closure x Control x Dump 



( r rP 
{SUCC 




(C, V, D) dec/ 

cont 

(C, SUCC, -D)dcc/cont 

(C, V, D) dec/ 

cont 

DEC (x[e], C, D) 
(C, (\x.t)[e\, D) dcc/cont 
DEC ((t ii)[e], C, D) 
DEC (J, C, D) 

(Cl, C[c []], £>}dcc/clos 
(C, r D n , -D)dec/cont 
(C, r LP o v, £>}dcc/cont 
(c, [], C ■ -D)dcc/clos 




((Xx.t)[e 
({to h)[e 



(J[e] 
(co Cl 
( r D n 



CU 1 o v 
((c) 
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([]) v , D) dcc / cont 
(C[c []], Vt, D) dcc/cont 
(C[[]vi], V , £>>dec/cont 



(D, ^)dec/dump 

(Co, C[[] £>}dec/clos 

DEC (v v x , C, D) 



{•, «}dcc/dump VAL 0) 

(C • -D, w)dcc/dump ~" * (C) w > -^/dec/cont 

We now can define a total function decompose over closures that maps a value closure to 
itself and a non- value closure to a decomposition into a potential redex, a control context, 
and a dump context. This total function uses three auxiliary functions decompose^,, 
decompose^, and decompose dump : 



decompose 
decompose^, 
decompose^ 
decompose dump 



Closure 

Closure x Control x Dump 
Control x Value x Dump 
Dump x Value — ► 

Definition 7.3. For any closure c, control context C, and dump context D, 

VAL (V) 



Value + (PotRed x Control x Dump) 
Value + (PotRed x Control x Dump) 
Value + (PotRed x Control x Dump) 
Value + (PotRed x Control x Dump) 



decompose^ (c, C, D) 
decompose^ (C, v, D) 
decompose dump (D, v) 



DEC (r, C, D'] 

VAL (v') 

DEC (r, C, D') 

VAL (v') 

DEC (r, C, D') 



if (c, C, -D)dcc/clos " 
if (c, C, -D)dcc/clos " 

if (C, V, £>)dec/cont 

if (C, v, D) dcc / cont 

if (D, v)dcc/dump —■ 
if (D, u)dcc/dump — * 



VAL («') 
* DEC (r, C", D') 

►* VAL (</) 

>* DEC (r, C", D') 

VAL («') 

DEC (r, C", £>') 



and decompose (c) = decompose^ (c, 



7.3.5. One-step reduction. We are now in position to define a partial function reduce over 
closed closures that maps a value closure to itself and a non-value closure to the next closure 
in the reduction sequence. This function is defined by composing the three functions above: 

reduce (c) = case decompose (c) 

of VAL (v) ]v 
| DEC (r, C, D) plug (contract (r, C, £>)) 
The function reduce is partial because of contract, which is undefined for stuck closures. 

Definition 7.4 (One-step reduction). For any closure c, c — > d if and only if reduce (c) = d . 



7.3.6. Reduction-based evaluation. Iterating reduce defines a reduction-based evaluation 
function. The definition below uses decompose to distinguish between values and non- 
values, and implements iteration (tail-) recursively with the partial function iterate: 



where 



evaluate (c) = iterate (decompose (c)) 
iterate (VAL (v)) = v 

iterate (DEC (r, C, D)) = iterate (decompose (plug (contract (r, C, £>)))) 
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The function evaluate is partial because a given closure might be stuck or reducing it might 
not converge. 

Definition 7.5 (Reduction-based evaluation). For any closure c, c — ►* v if and only if 
evaluate (c) = v. 

To close, let us adjust the definition of evaluate by exploiting the fact that for any 
closure c, plug(c, [],•)= c: 

evaluate (c) = iterate (decompose (plug (c, [], •))) 

In this adjusted definition, decompose is always applied to the result of plug. 

7.4. From the reduction semantics for applicative expressions to the SECD ma- 
chine. Deforesting the intermediate terms in the reduction-based evaluation function of 
Section 17.3.61 yields a reduction- free evaluation function in the form of a small-step abstract 
machine (Section 17.4. ip . We simplify this small-step abstract machine by fusing a part of 
its driver loop with the contraction function (Section I7.4.2P and compressing its 'corridor' 
transitions (Section |7.4.3[) . Unfolding the recursive data type of closures precisely yields the 
caller-save, stackless SECD abstract machine of Section [7.11 (Section I7.4.4"j) . 

7.4.1. Refocusing: from reduction-based to reduction-free evaluation. Following Danvy and 
Nielsen [45] , we deforest the intermediate closure in the reduction sequence by replacing the 
composition of plug and decompose by a call to a composite function refocus: 

evaluate (c) = iterate (refocus (c, [], •)) 

where 

f iterate (VAL («)) = v 

\ iterate (DEC (r, C, D)) = iterate (refocus (contract (r, C, D))) 
and refocus is optimally defined as continuing the decomposition in the current reduction 
context [45]: 

refocus (c, C, D) = decompose^ (c, C, D) 

Definition 7.6 (Reduction-free evaluation). For any closure c, c i— >j v if and only if 
evaluate (c) = v. 

7.4.2. Lightweight fusion: making do without driver loop. In effect, iterate is as the 'dri- 
ver loop' of a small-step abstract machine that refocuses and contracts. Instead, let 
us fuse contract and iterate and express the result with rewriting rules over a configu- 
ration (r, C, D)i teT . We clone the rewriting rules for decompose^., decompose^. ont , and 
decompose^ into refocusing rules, respectively indexing the configuration (c, C, D) dcc / c \ os 
as (c, C, D ) eva i, the configuration (C, v, D) dcc / cont as (C, v, D) cont , and the configuration 
( D , «)dcc/dum P as (D, v) dump : 

• instead of rewriting to VAL (v), the cloned rules rewrite to v; 

• instead of rewriting to DEC (r, C, D), the cloned rules rewrite to (r, C, D)it e r- 
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The result reads as follows: 



(V 




> (C, W, D) cont 


(SUCC,C,D) cval = 


> (C, SUCC, D) cont 


/i — ir i 
('n'[ej 




> (C,V,D) cont 


/ r i 

(x[e\ 


) C, -D)oval = 


> (x[e\, C, D) itei 


l(Xx.t)[e] 


i Ci D) ova] ~ 


> (C, (Xx.t)[e\, D) cont 


<(*o h)[e] 


i C, -D) val ~ 


> ((t *l)[e], C, -D)iter 


(J[e) 


i C) -D)cval = 


> (J, C, DWpt 


(co Cl 


i C) -D)cval = 


> (d , C[c []], D)eval 


( r £ n 


i Cj )eval = 


► (C, T* , -D) cont 


( r L> n O U 


i C, -D/eval = 


> (C, r D n o«, £>>cont 


((c) 


i C, -D/eval = 


► (c, [], C-£>) eV al 


([] 


, U) D) cont = 


> (D, v) dump 


<C[co[]], 


Vl, D) cont = 


> (co, C[[]vi], D) evai 


<C[[]t;i], 


vo, D) cont = 


> (v Vi, C, D)iter 




(*> w )dump = 






D, f)dump = 


> (C, V, L>) CO nt 



(x[e\, C, D) itcr => (v, C, D) cval if lookup(x,e) = v 

(SUCCrP, C, D)iter ( r n + T, C, D) cva i 

(((Ax.i)[e]) C, .D)iter =^ (*[ e ']) []) C" ^)eval where e' = extend(x, v , e) = (x,v) ■ e 

(^v,C,D) itcr => (rD^ov, C, D) cval 

{(nr> o v') V, C, D) iteI => (t/ [ ], £>')eval 

((to ii)[e], C, L>) itcr => ((i [e]) (ti[e]), C, D) eval 

(J,C,D) iteI => ( r ZT, C, D)eval 

The following proposition summarizes the situation: 

Proposition 7.7. For any closure c, evaluate (c) = v if and only if (c, [], •) e vaJ w - 
Proof: straightforward. The two machines operate in lockstep. □ 

7.4.3. Inlining and transition compression. The abstract machine of Section 17.4.21 while 
interesting in its own right (it is 'staged' in that the contraction rules are implemented 
separately from the congruence rules [14,69]), is not minimal: a number of transitions yield 
a configuration whose transition is uniquely determined. Let us carry out these hereditary, 
"corridor" transitions once and for all: 

• (x[e), C, £>)cvai [x[e], C, D) itcr (v, C, £>) cva i => (C, v, D) cont if lookup(x,e) = v 

• ({t ti)[e], C, D) cval ((t h)[e], C, D) iteI 

<(*o[e]) (ti[e}), C, D) cval (ti[e], C[(t [e}) [}}, D) cval 

• (J[e\, C, D) cval (J, C, D) itei (^, C, D) cva i (C, D) cont 

• (SUCC V, C, D) itcr => ( r n + V, C, D) cval (C, r n + V, D) cont 
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• ( r D^ V, C, 13 ) iter ( F D n o v, C, D)eval => (C, r D^ o V, D) cont 

The result reads as follows: 



(Vie] C D) a r = 




(x[e], C, £>) cva i = 


> (C, v, I3) CO nt if lookup(x,e) = v 


<(Az.t)[e], C, D) cval = 


> (C, {Xx.t)[e], D) cont 


((MiM C, Z3) cva i = 


> {hie], C[(t [e\) []], D) cval 


(J[e\, C, J D) cval = 


> (C, ^LP, D) cont 


(SUCC V, C, D) iter = 


> (C, r n + V, D) cont 


(((Ax.t)[e])u, C, Z3) itC r = 


> (t[e'], [], C ■ Z3)cvai where e' = extend(x,v,e 


((^ o </) u, C, D> iter = 


> (vv',[}, D% ei 


u, C, Z3) itcr = 


> (C, r Z3 n o v, D) cont 


([], U, Z?)cont = 


> (D, v) dump 


<C[(t[e]) []],*, I3) cont = 


> (t[e\, C[[]v], Z3) cval 


<C[[]t/], v, D) cont = 


> (w', C, Z3)iter 


(*) ^}dump — 


> V 


(C ■ D, W)dump = 


> {C, v, D) cont 



The eval-clauses for r n n , SUCC (which only occurs in the initial environment), Co c±, r D n , 
and r D 1 o v and the iter-clauses for x[e], (to ii)[e], and J all have disappeared: they were 
only transitory. The eval-clause for (c) has also disappeared: it is a dead clause here since 
plug has been refocused away. 

Proposition 7.8. For any closure c, evaluate (c) = v if and only if (c, [], •} CV ai v. 

Proof: immediate. We have merely compressed corridor transitions and removed one dead 
clause. □ 

7.4.4. Opening closures: from explicit substitutions to terms and environments. The ab- 
stract machine above solely operates on ground closures and the iter-clauses solely dispatch 
on applications of one value to another. If we (1) open the closures t[e] into pairs (t, e) and 
flatten the configuration ((i, e), C, D) cva ± into a quadruple (t, e, C, D) eval and (2) flatten 
the configuration (v v', C, -D} iter into a quadruple {v, v' , C, -D} app i y , we obtain an abstract 
machine that coincides with the caller-save, stackless SECD machine of Section 17.11 

The following proposition captures that the SECD machine implements the reduction 
semantics of Section 17.31 

Proposition 7.9 (syntactic correspondence). For any program t in the Xp J -calculus, 
t[(succ, SUCC) ■ 0]^* v if and only if (t[(succ, SUCC) • 0], [ ], «) cva i =>* v. 



Proof: this proposition is a simple corollary of the above series of propositions and of the 
observation just above. □ 
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7.5. Summary and conclusion. All in all, the syntactic and the functional correspon- 
dences provide a method to mechanically build compatible small-step semantics in the form 
of calculi (reduction semantics) and abstract machines, and big-step semantics in the form of 
evaluation functions. We have illustrated this method here for applicative expressions with 
the J operator, providing their first big-step semantics and their first reduction semantics. 

8. A SYNTACTIC THEORY OF APPLICATIVE EXPRESSIONS WITH THE J OPERATOR: 

IMPLICIT, CALLER-SAVE DUMPS 

The J operator capture the continuation of the caller and accordingly, the SECD ma- 
chine is structured as the expression continuation of the current function up to its point of 
call (the C component) and as a list of the delimited expression continuations of the pre- 
viously called functions (the D component). This architecture stands both for the original 
SECD machine (Section [2]) and for its modernized instances, whether the dump is managed 
in a callee-save fashion (Section [3]) or in a caller-save fashion (Section H]). In this section, we 
study a single representation of the context that is dynamically scanned in search for the 
context of the caller, as in Felleisen et al.'s initial take on delimited continuations [54] and 
in John Clements's PhD thesis work on continuation marks [27]. We start from a reduction 
semantics (Section l8.ip and refocus it into an abstract machine (Section l8.2p . 

8.1. Reduction semantics. We specify the reduction semantics as in Sections l7.3l and lE.H 
i.e., with its syntactic categories, a plugging function, a notion of contraction, a decompo- 
sition function, a one-step reduction function, and a reduction-based evaluation function. 

8.1.1. Syntactic categories. We consider a variant of the ApJ-calculus with one layer of 
context C and with delimiters (c) and (C) (shaded below) to mark the boundary between 
the context of a /3-redex that has been contracted, i.e., a function closure that has been 
applied, and the body of the A-abstraction in this function closure which is undergoing 
reduction: 



(programs) 


p : 


:= t[(succ, SUCC) ■ 0] 


(terms) 


t : 


■= r rf l x Xx.t | 1 1 | J 


(closures) 


c : 


:= r rP SUCC | t[e] \ c c \ r CP \ r (P o v 


(values) 


v : 


:=V SUCC (\x.t)[e\ | r (P \ r (P o v 


(potential redexes) 


r : 


:= x\e\ \ v v | J 


(substitutions) 


e : 


:= (x, v) ■ e 


(contexts) 


C : 


■■=[] 1 C[c[\] | C[[]v] | (C) 



Again, in the syntactic category of closures, r C n and r C 1 o v respectively denote a state 
appender and a program closure. Also again, values are therefore a syntactic subcategory 
of closures, and we make use of the syntactic coercion f mapping a value into a closure. 
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8.1.2. Plugging. Plugging a closure in a context is denned by induction over this context: 

([]) ^-)plug/cont > C 

{C[co[}} 

> < --l)plug/cont * (C, ^0 Cl)plug/cont 

(C[[ ] «i]> co) p iug/cont -» (C, c ci) p i ug/cont where ci = | «i 

((C)) c) p i U g/ cont — > (C, (c))pi U g/ con t 

Definition 8.1. For any closure c and context C, plug (C, c) = c' if and only if 

(C, c) plug/cont * C • 

8.1.3. Notion of contraction. The notion of reduction is specified by the following context- 
sensitive contraction rules over actual redexes: 

(Var) {x[e\, C) \— > (v, C) if lookup(x, e) = v 

(Beta succ ) (SUCC r rP, C) ^ ( r n + V, C) 

(Bet&Fc) {((^x.t)[e\) v, C) i— >• ((i[e']), C) where e' = extend(x , v , e) = (x,v) ■ e 
(Beta<M) { r C n v, C) ^ ( r C n o v, C) 
(Betapc) {( r C n o v') v, C) ^ (v' v, C) 

(Prop) (MiM C) ^ ((t [e\) (hie}), C) 

(J) (J, C) i — > ( r C n , C) where C = previous(C) 

where previous maps a context to its most recent delimited context, if any: 

previous(C\c [ ]]) = previous(C) 

previous(C[[ ] v]) = previous(C) 

previous({C)) = C 

Two of the contraction rules depend on the context: the J rule captures a copy of the 
context of the most recent caller and yields a state appender, and the /3-rule for program 
closures reinstates a previously captured copy of the context. As for the /3-rule for function 
closures, it introduces a delimiter. 

Definition 8.2. For any potential redex r and context C, contract (r, C) = (c, C) if and 
only if (r, C) ^ (c, C). 

8.1.4. Decomposition. Decomposition is essentially as in Section [7.3.41 except that there is 
no explicit dump component: 

(V, C)dcc/clos ~~ * (C, r ^ n }dec/cont 
{SU CC, C)dcc/clos ~~ * (C, SU CC) dec/cont 
( r n n [e], C) dcc / clos — > {C, r ^ n )dcc/cont 

(x[e\, C) dec/clos - DEC (z[e],C) 

((Ax.t)[e], C) dcc/c i os -> ((7, (Ax.t)[e]) dcc/cont 

((to*i)[e], C)dec/cio S -» DEC((toti)[e], C) 

(J[e], C} dec/dos - DEC (J, C) 

(cq Cl, C) dec / clos — > (Ci, C[c [ ]])dcc/clos 
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( F C n , C)dcc/clos ~ 


-> (C, r C n )dcc/cont 


( r C n o v, C) dec/clos - 


- (C, r C^o V ) dec/c 


(( c )> C)dcc/clos 


( c > (C))dec/clos 


([ ]> u )dec/cont 


■+ VAL» 


{C[CQ []], Wl)dcc/cont " 


-> (co, C[[] «i]) dec/( 


(C[[] Uo)dec/cont " 


■+ DEC (t^ vi, C) 


((C), f)dcc/cont ~ 


(C, u)(jec/coiit 



clos 



Definition 8.3. For any closure c, 

VAL(w) 



decompose (c) 



DEC (r, C) 



if (c, 
if (c, 



]) dec/ clos 
] )dec/clos 



VAL (u) 
DEC (r, C) 



8.1.5. One-step reduction and reduction-based evaluation. We are now in position to define 
a one-step reduction function (as in Sections 17.3.51 and IE. 1.5[) and an evaluation function 
iterating this reduction function (as in Section [7.3.61 and IE. 1.6|) . 



8.2. From reduction semantics to abstract machine. Repeating mutatis mutandis 
the derivation illustrated in Sections 17.41 and IE. 21 leads one to the following variant of the 
SECD machine: 

t[(succ, SUCQ-0] 
r n~ l | x | Xx.t | 1 1 | J 
V | SUCC | (Xx.t,e) | r CPo V | r CP 
| (x, v) ■ e 

[] | C[(t,e)[}] | C[[]v] | (C) 



(programs) p 

(terms) t 

(values) v 

(environments) e 

(contexts) C 



e, C) cval 
(x, e, C) cval 
(Xx.t, e, C) cval 
(to h, e, C) cval 
(J, e, C) cval 
(SUCC, V, C7) apply 
((Ax.t.e), C) apply 
frTW, v , C) apply 
( r C n , u, C) apply 

([]. U )cont 

<C[[KWcont 
((C),^) cont 



(c, w) cont 

(C> U )cont 

(C, (Ax.t,e)) cont 
(ti, e, C[(to,e) []]) cval 
(C, r C n ) cont 

(C, r n+r) cont 

<A ^Oapply 

(c, r c^ o v ) cont 

(*. e, C[[H> eval 

(«> U '> O apply 

(c, «) cont 



if lookup(x, e) = v 

if C" = previous (C) 
where e' = extend(x, v, e) 



Starting in the configuration (t, (succ, SUCC) ■ 0, []} cval makes this machine evaluate the 
program t. The machine halts with a value v if it reaches a configuration ([], v) t . 
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Alternatively (if we allow J to be used outside the body of a lambda-term and we let 
it denote the empty context), this machine evaluates a program t by starting in the config- 
uration (t, (succ, SUCC) ■ 0, ([])) cva i- It halts with a value v if it reaches a configuration 

([]' U )conf 

In either case, the machine is not in defunctionalized form [43,44]. Therefore, one 
cannot immediately map it into an evaluation function in CPS, as in Sections El [3l and[H 
The next two sections present two alternatives, each of which is in defunctionalized form 
and operates in lockstep with the present abstract machine. 

9. A SYNTACTIC THEORY OF APPLICATIVE EXPRESSIONS WITH THE J OPERATOR: 

EXPLICIT, CALLER-SAVE DUMPS 

Instead of marking the context and the intermediate closures, as in Section [HJ one can 
cache the context of the caller in a separate register, which leads one towards evaluatel ' _alt 
in Section 14.21 For an analogy, in some formal specifications of Prolog [17,49], the cut 
continuation denotes the previous failure continuation and is cached in a separate register. 

10. A SYNTACTIC THEORY OF APPLICATIVE EXPRESSIONS WITH THE J OPERATOR: 

INHERITING THE DUMP THROUGH THE ENVIRONMENT 

Instead of marking the context and the intermediate closures, as in Section [HJ or of 
caching the context of the caller in a separate register, as in Section one can cache the 
context of the caller in the environment, which leads one towards Felleisen's simulation 
(Section I4.5P and a lightweight extension of the CEK machine. Let us briefly outline this 
reduction semantics and this abstract machine. 

10.1. Reduction semantics. We specify the reduction semantics as in Section [8.11 

10.1.1. Syntactic categories. We consider a variant of the ApJ-calculus which is essentially 
that of Section 18.1.11 except that J is now an identifier and there are no delimiters: 



(programs) 


P ■ 


:= t[(succ,SUCC) ■ 0} 




(terms) 


t : 


:= r v? | x | Xx.t 1 1 




(closures) 


c : 


:= V SUCC | t[e] | cc 


r cr | r crov 


(values) 


v : 


:= V SUCC (\x.t)[e\ | 


r CP | r CPo V 


(potential redexes) 


r : 


:= x[e] v v 




(substitutions) 


e : 


:= (x,v) ■ e 




(contexts) 


C : 


■■= [] 1 C[c[}} | C[[]v] 





10.1.2. Plugging. The notion of reduction is essentially as that of Section [8.1.21 except that 
there is no control delimiter: 

([]) ^)plug/cont y C 

(C[co[]] 

(C[[ ] vi], c )pi ug / cont -> (C, c ci) p i ug/cont where a = | v\ 
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10.1.3. Notion of contraction. The notion of reduction is essentially as that of Section [8.1. 31 
except that there is no rule for J and there are no delimiters: 

(Var) (x[e\, C) i— > (v, C) if lookup(x , e) =v 

(Beta succ ) (SUCC V, C) ^ ( r n + V, C) 

(Beta FC ) (((Xx.t)[e\) v, C) i-» (t[e'], C) where e' = (J, r C n ) • (<c,v) • e 

(Beta 5A ) ( r <? n u, (7) i-» ( r (7 n o v, C) 

(Betap C ) (( r C n o v') v, C) i-» (u y u, (7') 

(Prop) ((toti)[e], C)^((i [e])(*i[e]), C) 
In the /3-rule for function closures, J is dynamically bound to the current context. 

10.1.4. Decomposition. Decomposition is essentially as in Section [8.1. 44 except that there 
is no rule for J and there are no delimiters: 



(V, 


^)dec/clos 


■> (C, '"j'ly dec/coat 


(SUCC, C) dec / c j os 


■» (C, 5'[/CC) dcc / cont 


{ r rP[e]> 


C)dec/clos 


■* (C) rn_l )dcc/cont 


(x[e], 


C)dec/clos 


DEC(a[e], C) 


((Xx.t)[e\, 


C)dec/clos 


■* (C, (Ax.t)[e]) dcc/cont 


((to h)[e], 


C)dec/clos 


* DEC((t ti)[e],C) 


(co Cl, 


C)dec/clos 


■> (ci, C[c []])dcc/clos 


( r c^, 


C)dec/clos 


-> (C, r C n )dcc/cont 


( r C n o u, 


^)dec/clos 


■> (C, r C o u)dec/cont 


([] 


> ^)dec/cont 


-» VAL» 


(Ch[]], 


^l)dec/cont 


-> (c , C[[] Ul])dec/clos 


(C[[]v 1 ], 


u 0/dec/cont 


-> DEC(u ui, C) 



10.2. From reduction semantics to abstract machine. Repeating mutatis mutandis 
the derivation illustrated in Sections 17.41 and IE.2I leads one to the following variant of the 
CEK machine: 



(programs) 


P 


:= t[(succ, SUCC)-0] 


(terms) 


t 


:= r n n 


x Xx.t tt 


(values) 


V 


:= V 


SUCC \ (Xx.t,e) 


(environments) 


e 


:= | 


(x, v) ■ e 


(contexts) 


C 


:=[] 1 


C[(t,e)[}} | C[[]v 
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(c, w) cont 

( C > W )cont 

(C, (Xx.t,e)) cont 

(h, e, C[(i ,e) []]) cval 

(C, r n + V) cont 

(*> e > C)cval 
(«> U '> ^Oapply 



if lookup(x, e) 



where e' = extend(J, r C n , extend(x, v, e)) 



(*> e > C ')cval 

(Ax.t, e, C) cval 
(to *i, e, C) eval 

(SUCC, V, C) apply 
((Ax.t.e), u, C) apply 
o v>, v, C) apply 
( r ^ n , v, C) apply 

<[]' U )cont V 

(C[(t,e)[]],v) cont =}► (t, e, C[[H> eval 

(C[[]^], V ) cont =► («, t/, C7) apply 

This machine evaluates a program t by starting in the configuration 

(t, (succ,SUCC)-0, []) cval . 

It halts with a value v if it reaches a configuration ([], v) cont . 

Alternatively (if we allow J to be used outside the body of a lambda-term and we 
let it denote the empty context), this machine evaluates a program t by starting in the 
configuration 

(t, (J,[])-(suec,SUCC)-0, []) cval . 
It halts with a value v if it reaches a configuration ([], v) cont . 

In either case, the machine is in defunctionalized form. Refunctionalizing it yields 
a continuation-passing evaluation function. Refunctionalizing its closures and mapping 
the result back to direct style yields the compositional evaluation functions displayed in 
Section [4.51 i- e -> Felleisen's embedding of the J operator in Scheme [51]. 



11. Summary and conclusion 

We have presented a rational deconstruction of the SECD machine with the J oper- 
ator, through a series of alternative implementations, in the form of abstract machines 
and compositional evaluation functions, all of which are new. We have also presented the 
first syntactic theories of applicative expressions with the J operator. In passing, we have 
shown new applications of refocusing and defunctionalization and new examples of control 
delimiters and of both pushy and jumpy delimited continuations in programming practice. 

Even though they were the first of their kind, the SECD machine and the J operator 
remain computationally relevant today: 

• Architecturally, and until the advent of JavaScript run-time systems [57], the SECD ma- 
chine has been superseded by abstract machines with a single control component instead 
of two (namely C and D). In some JavaScript run-time systems, however, methods have 
a local stack similar to C to implement and manage their expression continuation, and 
a global stack similar to D to implement and manage command continuations, i.e., the 
continuation of their caller. 
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• Programmatically, and until the advent of first-class continuations in JavaScript [28], the J 
operator has been superseded by control operators that capture the current continuation 
(i.e., both C and D) instead of the continuation of the caller (i.e., D). In the Rhino 
implementation of JavaScript, however, the control operator captures the continuation 
of the caller of the current method, i.e., the command continuation instead of both the 
expression continuation and the command continuation. 

At any rate, as we have shown here, both the SECD machine and the J operator fit the 
functional correspondence [3,4,6,7,13,16,35,36] as well as the syntactic correspondence [12, 
14,15,34,36,45], which made it possible for us to mechanically characterize them in new 
and precise ways. 

All of the points above make us conclude that new abstract machines should be defined 
in defunctionalized form today, or at least be made to work in lockstep with an abstract 
machine in defunctionalized form. 

12. On the origin of first-class continuations 
We have shown that jumping and labels are not essentially connected with strings 
of imperatives and in particular, with assignment. Second, that jumping is not 
essentially connected with labels. In performing this piece of logical analysis we 
have provided a precisely limited sense in which the "value of a label" has mean- 
ing. Also, we have discovered a new language feature, not present in current 
programming languages, that promises to clarify and simplify a notoriously un- 
tidy area of programming — that concerned with success/ failure situations, and the 
actions needed on failure. - Peter J. Landin, 1965 [82, page 133] 

It was Strachey who coined the term "first-class functions" [113, Section 3.5.1]H In turn 
it was Landin who, through the J operator, invented what we know today as first-class 
continuations [58]: like Reynolds for escape [102], Landin defined J in an unconstrained way, 
i.e., with no regard for it to be compatible with the last-in, first-out allocation discipline 
prevalent for control stacks since Algol 60@ 

Today, 'continuation' is an overloaded term, that may refer 

• to the original semantic description technique for representing 'the meaning of the rest 
of the program' as a function, the continuation, as multiply co-discovered in the early 
1970's [103]; or 

• to the programming-language feature of first-class continuations as typically provided by 
a control operator such as J, escape, or call/cc, as invented by Landin. 

Whether a semantic description technique or a programming-language feature, the goal of 
continuations was the same: to formalize Algol's labels and jumps. But where Wadsworth 
and Abdali gave a continuation semantics to Algol, and as illustrated in the beginning of 
Section [H Landin translated Algol programs into applicative expressions in direct style. In 
turn, he specified the semantics of applicative expressions with the SECD machine, i.e., 
using first-order means. The meaning of an Algol label was an ISWIM 'program closure' 

^ "Out of Quint's dictum: To be is to be the value of a variable, grew Strachey 's 'first-class citizens'." Peter 
J. Landin, 2000 [86, page 75] 

^ "Dumps and program- closures are data-items, with all the implied latency for unruly multiple use and 
other privileges of first-class-citizenship." Peter J. Landin, 1997 [85, Section 1] 
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as obtained by the J operator. Program closures were denned by extending the SECD 
machine, i.e., still using first-order means. 

Landin did not use an explicit representation of the rest of the computation in his 
direct semantics of Algol 60, and for that reason he is not listed among the co-discoverers of 
continuations [103]. Such an explicit representation, however, exists in the SECD machine, 
in first-order form — the dump — which represents the rest of the computation after returning 
from the current function call. 

In an earlier work [35], Danvy has shown that the SECD machine, even though it is 
first-order, directly corresponds to a compositional evaluation function in CPS — the tool of 
choice for specifying control operators since Reynolds's work [102]. In particular, the dump 
directly corresponds to a functional representation of control, since it is a defunctionalized 
continuation. In the light of defunctionalization, Landin therefore did use an explicit repre- 
sentation of the rest of the computation that corresponds to a function, and for that reason 
we wish to see his name added to the list of co-discoverers of continuations. 
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Appendices 

Appendix lAl demonstrates how two programs, before and after defunctionalization, do not 
just yield the same result but also operate in lockstep. The three following appendices illus- 
trate the callee-save, stack-threading features of the evaluator corresponding to the SECD 
machine by contrasting them with a caller-save, stackless evaluator for the pure A-calculus. 
We successively consider a caller-save, stackless evaluator and the corresponding abstract 
machine (Appendix iBj) . a callee-save, stackless evaluator and the corresponding abstract 
machine (Appendix ICl) . and a caller-save, stack-threading evaluator and the correspond- 
ing abstract machine (Appendix [D]) . Finally, Appendix [El demonstrates how to go from a 
reduction semantics of the A/5-calculus to the CEK machine. 

Appendix A. Defunctionalizing a continuation-passing version 
of the Fibonacci function 

We start with the traditional Fibonacci function in direct style (Section lA.lj) . and then 
present its continuation-passing counterpart before (Section IA.2j) and after (Section IA.3[) 
defunctionalization. To pinpoint that these two functions operate in lockstep, we equip 
them with a trace recording their calling sequence, and we show that they yield the same 
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result and the same trace. (One can use the same tracing technique to prove Proposition ^. 21 
in Section [2.21 ) 

A.l. The traditional Fibonacci function. We start from the traditional definition of 
the Fibonacci function in ML: 
fun fib n 

= if n <= 1 
then n 

else (fib (n - 1)) + (fib (n - 2)) 

fun mainO n 
= fib n 

So for example, evaluating mainO 5 yields 5. 

A. 2. The Fibonacci function in CPS. To CPS-transform, we first name all intermediate 
results and sequentialize their computation, assuming a left-to-right order of evaluation [32]: 

fun fib n 

= if n <= 1 
then n 

else let val vl = fib (n - 1) 
val v2 = fib (n - 2) 
in vl + v2 
end 

fun mainO ' n 

= let val v = fib n 
in v 
end 

We then give fib an extra argument, the continuation: 
fun fib_c (n, k) 
= if n <= 1 
then k n 

else fib_c (n - 1 , 

fn vl => fib_c (n - 2, 

fn v2 => k (vl + v2))) 

fun mainl n 

= fib_c (n, fn v => v) 

So for example, evaluating mainl 5 yields 5. 

A. 3. The Fibonacci function in CPS, defunctionalized. To defunctionalize the Fi- 
bonacci function in CPS, we consider its continuation, which has type int -> int. Each 
inhabitant of this function space arises as an instance of the initial continuation in mainl 
or of the two continuations in fib_c. We therefore represent the function space as a sum 
with three summands, one for each A-abstraction, and we interpret each summand with the 
body of each of these A-abstractions, using apply_cont: 
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type res = int 

datatype cont = CO 

I CI of res * cont 
I C2 of int * cont 

fun apply_cont (CO, v) 
= v 

I apply_cont (CI (vl, c) , v2) 

= apply_cont (c, vl + v2) 
I apply_cont (C2 (n, c) , vl) 

= fib_c_def (n - 2, CI (vl, c)) 
and fib_c_def (n, c) 
= if n <= 1 

then apply_cont (c, n) 

else fib_c_def (n - 1, C2 (n, c)) 

fun main2 n 

= fib_c_def (n, CO) 

Defunctionalization is summarized with the following two tables, the first one for the func- 
tion abstractions and the corresponding sum injections into the data type cont0 and the 
second one for the function applications and the corresponding calls to the apply function 
dispatching over summands: 

• introduction 



function abstraction 


sum injection 


fn v => v 


CO 


fn v2 => k (vl + v2) 


CI (vl, c) 


fn vl => fib_c (n - 2, fn v2 => k (vl + v2)) 


C2 (n, c) 



• elimination 



function application 


case dispatch 


k n 


apply_cont (c, n) 


k (vl + v2) 


apply_cont (c, vl + v2) 



So for example, evaluating main2 5 yields 5. 

A. 4. The Fibonacci function in CPS with a trace. We can easily show that applying 
mainl and main2 as defined above to the same integer yields the same result, but we want to 
show a stronger property, namely that they operate in lockstep. To this end, we equip f ib_c 
with a trace recording its calls with the value of its first argument. (It would be simple to 
trace its returns as well, i.e., the calls to the continuation.) 

Representing the trace as a list, the Fibonacci function in CPS reads as follows: 
type res = int 

(* fib_c : int * (res * int list -> 'a) -> 'a *) 
fun fib_c (n, k, T) 
= if n <= 1 
then k (n, T) 



Which the cognoscenti will recognize as Daniel P. Friedman's "data-structure continuations" [59,119]. 
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else fib_c (n - 1, 

fn (vl, T) => fib_c (n - 2, 

fn (v2, T) => k (vl + v2, T) , 
(n - 2) : : T) , 

(n - 1) : : T) 

(* main3 : int -> res * int list *) 
fun main3 n 

= fib_c (n, fn (v, T) => (v, T) , n :: nil) 

So for example, evaluating main3 5 yields (5, [1,0, 1,2, 3, 0,1, 2, 1,0, 1,2, 3, 4, 5]). 

A. 5. The Fibonacci function in CPS with a trace, defunctionalized. Proceeding 
as in Section [A, 31 the corresponding defunctionalized version reads as follows; fib_c_def is 
equipped with a trace recording its calls with the value of its first argument. (Its returns, 
i.e., the calls to apply_cont, could be traced as well.) 
type res = int 

datatype cont = CO 

I CI of res * cont 
I C2 of int * cont 

(* apply_cont : cont * res * int list -> res * int list *) 
fun apply_cont (CO, v, T) 
= (v, T) 

I apply_cont (CI (vl, c) , v2, T) 

= apply_cont (c, vl + v2, T) 
I apply_cont (C2 (n, c) , vl , T) 
= fib_c_def (n - 2, CI (vl, c) , (n - 2) : : T) 
(* fib_c_def : int * cont * int list -> res * int list *) 
and fib_c_def (n, c, T) 
= if n <= 1 

then apply_cont (c, n, T) 

else fib_c_def (n - 1 , C2 (n, c) , (n - 1) : : T) 

(* main4 : int -> res * int list *) 
fun main4 n 

= fib_c_def (n, CO, n :: nil) 

So for example, evaluating main4 5 yields (5, [1,0, 1,2, 3, 0,1, 2, 1,0, 1,2, 3, 4, 5]). 

A. 6. Lockstep correspondence. 

Definition A.l. We define 7£(k, c) as 

Vv.VT.k (v, T) = a 44> apply_cont (c, v, T) = a 

where "e = a" means "there exists an ML value a such that evaluating the ML expression 
e yields a." 

Lemma A. 2. TZ(fn (v, T) => (v, T), CO) 

Proof: immediate. □ 
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Lemma A. 3. Vvl.VkAc such that Ufa c).7£(fn (v2, T) => k (vl + v2, T), CI (vl, c)). 
Proof: 

By (3 V reduction, (fn (v2, T) => k (vl + v2, T)) (v2, T) yields the same value as k 
(vl + v2, T). 

By definition, apply_cont (CI (vl, c) , v2, T) yields the same value as apply_cont (c, 
vl + v2, T). 

Suppose that k (vl + v2, T) = a holds. Then since 7Z(k, c), apply_cont (c, vl + v2, 
T) = a also holds, and vice- versa. □ 

Lemma A. 4. Vn.Vk A c such that TZ(k, c). 

1. fib_c (n, k, T) = a 44> fib_c_def (n, c, T) = a 

2. 7£(fn (vl, T) => fib_c (n, fn (v2, T) => k (vl + v2, T), n :: T), C2 (n+2, c)) 
Proof: by simultaneous course-of-value induction. □ 
Theorem A. 5. Vn.main3 n = a <^=> main4 n = a 

Proof, a consequence of Lemmas IA.2I and IA.41 □ 

The two versions, before and after defunctionalization, therefore operate in lockstep, 
since they yield the same trace and the same result. 

Appendix B. A caller-save, stackless evaluator 

AND THE CORRESPONDING ABSTRACT MACHINE 

B.l. The evaluator. The following evaluator for the pure call-by-value A-calculus (i.e., 
the language of Section [1.51 without constants and the J operator) is standard. As pointed 
out by Reynolds [102], it depends on the evaluation order of its metalanguage (here, call by 
value) : 

datatype value = FUN of value -> value 

(* eval : term * value Env.env -> value *) 
fun eval (VAR x, e) 

= Env. lookup (x, e) 
I eval (LAM (x, t) , e) 

= FUN (fn v => eval (t, Env. extend (x, v, e))) 
I eval (APP (tO, tl) , e) 
= let val (FUN f) = eval (tO, e) 
in f (eval (tl, e)) 
end 

fun evaluate t 

= eval (t, Env.mt) 

The evaluator is stackless because it does not thread any data stack. It is also caller-save 
because in the clause for applications, when to is evaluated, the environment is implicitly 
saved in the context in order to evaluate tl later on. In other words, the environment is 
solely an inherited attribute. 
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B. 2. The abstract machine. As initiated by Reynolds [4, 102], closure-converting the 
data values of an evaluator, CPS transforming its control flow, and defunctionalizing its 
continuations yields an abstract machine. For the evaluator above, this machine is the CEK 
machine [53], i.e., an eval-continue abstract machine where the evaluation contexts and the 
continue transition function are the defunctionalized counterparts of the continuations of 
the evaluator just above: 

(terms) t ::= x \ Xx.t \ it 

(values) v ::= [x, t, e] 

(environments) e ::= | (x,v) ■ e 

(contexts) k ::= END | ARG(t,e,fc) | FUN(v,fc) 

(x, e, fc) eva i => (k, v) cont if lookup(x, e) = v 

(Xx.t, e, A)) eva j =>• (k, [x, t, e]) con t 
(t h, e, k) cval => (t , e, ARG(ti, e, k)) cval 

(END, v) cont v 

(ARG(t,e,/c), v) cont (t, e, FUN(u, k)) eva i 

(FUN([x, t, e], k), f)cont => (t, e', fc) eV al where e' = extend(x, v , e) 

This machine evaluates a closed term t by starting in the configuration (t, 0, END) cva i. It 
halts with a value v if it reaches a configuration (END, u) CO nt- 

Appendix C. A callee-save, stackless evaluator 

AND THE CORRESPONDING ABSTRACT MACHINE 

C. l. The evaluator. The following evaluator is a callee-save version of the evaluator of 
Appendix[Bj Whereas the evaluator of Appendix IE1 maps a term and an environment to the 
corresponding value, this evaluator maps a term and an environment to the corresponding 
value and the environment. This way, in the clause for applications, the environment does 
not need to be implicitly saved since it is explicitly returned together with the value of to. 
In other words, the environment is not solely an inherited attribute as in the evaluator of 
Appendix [Bj it is a synthesized attribute as well. 

Functional values are passed the environment of their caller, and eventually they return 
it. The body of function abstractions is still evaluated in an extended lexical environment, 
which is returned but then discarded. Otherwise, environments are threaded through the 
evaluator as inherited attributes: 

datatype value = FUN of value * value Env.env -> value * value Env.env 

(* eval : term * value Env.env -> value * value Env.env *) 
fun eval (VAR x, e) 

= (Env. lookup (x, e) , e) 
I eval (LAM (x, t) , e) 
= (FUN (fn (vO, eO) => let val (vl, el) = eval (t, Env. extend (x, vO, e)) 

in (vl , eO) end) , 

e) 
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I eval (APP (tO, tl) , e) 
= let val (FUN f , eO) = eval (tO, e) 
val (v, el) = eval (tl, eO) 

in f (v, el) end 

fun evaluate t 

= let val (v, e) = eval (t, Env.mt) 
in v end 

Operationally, one may wish to note that unlike the evaluator of Appendix[Bl this eval- 
uator is not properly tail recursive since the evaluation of the body of a function abstraction 
no longer occurs in tail position [30,101]. 

C.2. The abstract machine. As in Appendix IB"| closure-converting the data values of 
this evaluator, CPS-transforming its control flow, and defunctionalizing its continuations 
yields an abstract machine. This machine is a variant of the CEK machine with callee-save 
environments; its terms, values, and environments remain the same: 

(contexts) k ::= END | ARG(t,fc) | FUN(t>,£;) | RET(e, k) 

(x, e, k) eyal (k, v, e) CO rit if lookup(x, e) = v 

(Xx.t, e, fc) cva i (k, [x,t,e], e) cont 
(t ti, e, /c) cva i (t , e, ARG(ti, k)) cval 

(END, v, e) cont v 

(ARG(t,/c), v, e) cont ^ E (t, e, FUN(w, k)) cval 

(FUN([x, t, e'] } k), v, e) con t =^E (t, e" , RET(e, fc)) eva i where e" = extend(x,v,e') 

(RET(e',/c), v, e) CO nt =^E (k, v, e') cva i 

This machine evaluates a closed term t by starting in the configuration (t, 0, END) eva j. It 
halts with a value v if it reaches a configuration (END, v, e) con t. 

C.3. Analysis. Compared to the CEK machine in Section lB.21 there are two differences 
in the datatype of contexts and one new transition rule. The first difference is that envi- 
ronments are no longer saved by the caller in ARG contexts. The second difference is that 
there is an extra context constructor, RET, to represent the continuation of the non-tail 
call to the evaluator over the body of function abstractions. The new transition interprets 
a RET constructor by restoring the environment of the caller before returning. 

It is simple to construct a bisimulation between this callee-save machine and the CEK 
machine. 
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Appendix D. A caller-save, stack-threading evaluator 

AND THE CORRESPONDING ABSTRACT MACHINE 

D.l. The evaluator. In a stack-threading evaluator, a data stack stores intermediate val- 
ues after they have been computed but before they are used. Evaluating an expression leaves 
its value on top of the data stack. Applications therefore expect to find their argument and 
function on top of the data stackF^I 

Several design possibilities arise. First, one can choose between a single global data 
stack used for all intermediate values (i.e., as in Forth) or one can use a local data stack for 
each function application (i.e., as in the SECD machine and in the JVM). For the purpose 
of illustration, we adopt the latter since it matches the design of the SECD machine. 

Since there is one local data stack per function application, then this data stack can 
be chosen to be saved by the caller or by the callee. Though the former design might be 
more natural, we again adopt the latter in this illustration since it matches the design of 
the SECD machine. 

If there is a local, callee-save data stack, then functional values are passed their argu- 
ment and a data stack, and return a value and a data stack. One can choose instead to 
pass the argument to the function on top of the stack and leave the return value on top of 
the stack (i.e., as in Forth). We adopt this design here, for a local callee-save data stack: 

datatype value = FUN of value list -> value list 

(* eval : term * value list * value Env.env -> value *) 
fun eval (VAR x, s, e) 

= Env. lookup (x, e) : : s 
I eval (LAM (x, t) , s, e) 
= FUN (fn (vO : : sO) 

=> let val (vl :: si) = eval (t, nil, Env. extend (x, vO, e)) 
in (vl : : sO) end) : : s 
I eval (APP (tO, tl) , s, e) 
= let val sO = eval (tO, s, e) 

val (v :: FUN f : : si) = eval (tl, sO, e) 
in f (v : : si) end 

fun evaluate t 

= let val (v : : s) = eval (t, nil, Env.mt) 
in v end 

Functional values are now passed the data stack of their caller and they find their 
argument on top of it. The body of a function abstraction is evaluated with an empty data 
stack, and yields a stack with the value of the body on top. This value is returned to the 
caller on top of its stack. 



If evaluation is left-to-right, the argument will be evaluated after the function and thus will be on top 
of the data stack. Some shuffling of the stack can be avoided if the evaluation order is right-to- left, as in the 
SECD machine or the ZINC abstract machine. 
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D.2. The abstract machine. As in Appendix [Cj one may wish to note that functions 
using local callee-save data stacks are not properly tail-recursive, though functions using 
global or local caller-save data stacks can be made to be. 

As in Appendix [B] and [Cl closure converting the data values of this evaluator, CPS 
transforming its control flow, and defunctionalizing its continuations yields an abstract 
machine. This machine is another variant of the CEK machine with a data stack; its terms, 
values, and environments remain the same: 

(contexts) k ::= END | ARG(t,e,k) | FUN(fe) | RET(s, k) 

{x, s, e, k) cval =^ s (k, v : : s) cont if lookup(x, e) = v 

(Xx.t, s, e, k) cval =^ s {k, [x,t,e] :: s) cont 
(to h, s, e, k) cval => s {to, s, e, ARG(*i, e, fc)) eva i 

(END, v : : s) cont => s v 

(ARG(t, e, k), s) cont =4> 5 {t, s, e, FUN(/c)) eva i 

(FUN(fc), v : : [x,t, e] : : s) CO nt =^5 (t, nil, e', RET(s, k)) cva \ where e' = extend(x, v, e) 

(RET(s', k), v :: s) cont =^ s (k, v.: s') cont 

This machine evaluates a closed term t by starting in the configuration (t, nil, 0, END) eva i. 
It halts with a value v if it reaches a configuration (END, v : : s) con t. 

D. 3. Analysis. Compared to the CEK machine in Section TB. 21 there are two differences in 
the datatype of contexts and one new transition rule. The first difference is that intermediate 
values are no longer saved in FUN contexts, since they are stored on the data stack instead. 
The second difference is that there is an extra context constructor, RET, to represent the 
continuation of the non-tail call to the evaluator over the body of function abstractions (i.e., 
a continuation that restores the caller's data stack and pushes the function return value on 
top). The new transition interprets a RET constructor by restoring the data stack of the 
caller and pushing the returned value on top of it before returning. 

It is simple to construct a bisimulation between this stack-threading machine and the 
CEK machine. 

Appendix E. From reduction semantics to abstract machine 

As a warmup to Sections 17.31 and 17.41 we present a reduction semantics for applicative 
expressions (Section IE. 1|) and we derive the CEK machine from this reduction semantics 
(Section MM- 

E. l. A reduction semantics for applicative expressions. The A/9-calculus is a minimal 
extension of Curien's original calculus of closures Xp [31] to make it closed under one- 
step reduction [14]. We use it here to illustrate how to go from a reduction semantics 
to an abstract machine. To this end, we present its syntactic categories (Section IE. 1 . 1|) ; 
a plug function mapping a closure and a reduction context into a closure by filling the 
given context with the given closure (Section IE.1.2|) ; a contraction function implementing 
a context-insensitive notion of reduction (Section IE.1.3[) and therefore mapping a potential 
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redex into a contractum; and a decomposition function mapping a non-value term into a 
potential redex and a reduction context (Section IE.1.4|) . We are then in position to define 
a one-step reduction function (Section IE.1.5|) and a reduction-based evaluation function 
(Section EX6]). 

E.l.l. Syntactic categories. We consider a variant of the Ap-calculus with names instead 
of de Bruijn indices, and with the usual reduction context C embodying a left-to-right 
applicative-order reduction strategy. 



(terms) 


t : 


:= x Xx.t 1 1 


(closures) 


c : 


:= t[e] c c 


(values) 


v : 


:= (Xx.t)[e\ 


(potential redexes) 


r : 


:= x[e] v v 


(substitutions) 


e : 


:= (x,v) ■ e 


(contexts) 


C : 


■■=[} 1 C[[]c] | C[v[]] 



Values are therefore a syntactic subcategory of closures, and in this section, we make use 
of the syntactic coercion j mapping a value into a closure. 

E.1.2. Plugging. Plugging a closure in a context is defined by induction over this con- 
text. We express this definition as a state-transition system with one intermediate state, 
(c, C) p i ug , an initial state (c, C) p i ug , and a final state c. The transition function incremen- 
tally peels off the given control context: 

c 

(C, c c l)plug 

(C, c ci) p iug where c = T 

plug over closures and contexts that fills the given 

plug : Closure x Control — ► Closure 

Definition E.l. For any closure c and context C, plug (C, c) = c' if and only if (c, C)pi ug — 
c'. 

E.l. 3. Notion of contraction. The notion of reduction over applicative expressions is spec- 
ified by the following context-insensitive contraction rules over actual redexes: 

(Var) x[e] i— ► v if lookup(x, e) = v 

(Beta) ((Xx.t)[e\) v \—> t[s'] where s' = extend(x, v, e) = (x,v) ■ e 

(Prop) (toti)[e]"-»(to[e])(ti[e]) 

For closed closures (i.e., closures with no free variables), all potential redexes are actual 
ones. 

We now can define by cases a total function contract that maps a redex to the corre- 
sponding contractum: 



([], c) p i ug -> 
(C[[] a], co) p i ug -> 
(C[v []], ci) p i ug -> 
We now can define a total function 
closure into the given context: 
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contract : PotRed — > Closure 
Definition E.2. For any potential redex r, contract (r) = c if and only if r i— > c. 

E.1.4. Decomposition. There are many ways to define a total function mapping a value 
closure to itself and a non-value closure to a potential redex and a reduction context. In 
our experience, the following definition is a convenient one. It is a state-transition system 
with two intermediate states, (c, C% ec / c ios and (C, w) dcc / cont , an initial state (c, []}dec/cios 
and two final states VAL (v) and DEC (r, C). If possible, the transition function from 
the state (c, C% ec /cios decomposes the given closure c and accumulates the corresponding 
reduction context C. The transition function from the state (C, f)dec/cont dispatches over 
the given context. 



(x[e] 


; C/dec/clos 


■+ DEC(x[e],C) 


((Xx.t)[e] 


! C)dcc/clos 


-> (C, (Ax.t)[e]) dcc/cont 


((to h)[e] 


! C)dcc/clos 


- DEC (Mi) [e], C) 


(en ci 


; C)dcc/clos 


"* ( c 0i C[[] c l])dcc/clos 


([] 


j ^)dec/cont _ 


-> VAL(w) 


<<?[[] Cl ], 


v 0/dec/ccmt 


-> (ci, C[-U []]}dcc/clos 


(C[v []], 


^l)dec/cont _ 


■* DEC(u ui, C) 



We now can define a total function decompose over closures that maps a value closure 
to itself and a non- value closure to a decomposition into a potential redex, a control context, 
and a dump context. This total function uses two auxiliary functions decompose^ and 
decompose^: 

decompose : Closure — > Value + (PotRed x Context) 
decompose^, : Closure x Context — ► Value + (PotRed x Context) 
decompose^. ont : Context x Value — > Value + (PotRed x Context) 

Definition E.3. For any closure c, value v, and context C, 

decompose' (c C) - { VAL {v ' ] * (c ' C)d ^ s ^* VAL ^ 

decompose^ (c, C) - j DEC (r, C) if (c, C) dec/clos -* DEC (r, C") 

decompose' f<7 v) ~ I VAL K) if V)dcc / cont ^* VAL K) 

decompose cont ^, t;; - | DEC (r, C") if (C, ^) dcc/cont ->* DEC (r, C") 

and decompose (c) = decompose^, (c, [ ]). 



E.1.5. One-step reduction. We are now in position to define a total function reduce over 
closed closures that maps a value closure to itself and a non-value closure to the next closure 
in the reduction sequence. This function is defined by composing the three functions above: 

reduce (c) = case decompose (c) 

of VAL (v) T v 

| DEC (r, C) =► plug (contract (r), C) 
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The function reduce is partial because of contract, which is undefined for stuck closures. 
Graphically: 

reduce 

o >■ o 




o s- o 

contract 



Definition E.4 (One-step reduction). For any closure c, c — ► d if and only if reduce (c) = d . 

E.1.6. Reduction-based evaluation. Iterating reduce defines a reduction-based evaluation 
function. The definition below uses decompose to distinguish between values and non- 
values, and implements iteration (tail-) recursively with the partial function iterate: 

evaluate (c) = iterate (decompose (c)) 

where 

( iterate (VAL (v)) = v 

\ iterate (DEC (r, C)) = iterate (decompose (plug (contract (r), C))) 
The function evaluate is partial because reducing a given closure might not converge. 
Graphically: 



reduce reduce 

o >. o s- o 




O S- O O s- O O 9- 

contract contract contract 

Definition E.5 (Reduction-based evaluation). For any closure c, c — >* v if and only if 
evaluate (c) = v. 

To close, let us adjust the definition of evaluate by exploiting the fact that for any 
closure c, plug(c, []) = c: 

evaluate (c) = iterate (decompose (plug (c, []))) 
In this adjusted definition, decompose is always applied to the result of plug. 

E.2. From the reduction semantics for applicative expressions to the CEK ma- 
chine. Deforesting the intermediate terms in the reduction-based evaluation function of 
Section IE. 1.61 yields a reduction-free evaluation function in the form of a small-step ab- 
stract machine (Section IE.2.1|) . We simplify this small-step abstract machine by fusing 
a part of its driver loop with the contraction function (Section IE.2.2j) and compressing its 
'corridor' transitions (Section lE.2,3h . Unfolding the recursive data type of closures precisely 
yields the caller-save, stackless CEK machine of Section [B.2I (Section IE . 2~4|) . 
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E.2.1. Refocusing: from reduction-based to reduction-free evaluation. Following Danvy and 
Nielsen [45] , we deforest the intermediate closure in the reduction sequence by replacing the 
composition of plug and decompose by a call to a composite function refocus: 

evaluate (c) = iterate (refocus (c, [ ])) 

where 

f iterate (VAL (v)) = v 

\ iterate (DEC (r, C)) = iterate (refocus (contract (r), C)) 
and refocus is optimally defined as continuing the decomposition in the current reduction 
context [45]: 

refocus (c, C) = decompose^ (c, C) 
This evaluation function is reduction-free because it no longer constructs each intermediate 
closure in the reduction sequence. 
Graphically: 



o o o 




— — — O 5>- o — — — — — — — >-o o — — — — — — — *-o s- 

contract refocus contract refocus contract 

Definition E.6 (Reduction- free evaluation). For any closure c, c — >* v if and only if 
evaluate (c) = v. 

E.2.2. Lightweight fusion: making do without driver loop. In effect, iterate is as the 'driver 
loop' of a small-step abstract machine that refocuses and contracts. Instead, let us fuse 
contract and iterate and express the result with rewriting rules over a configuration (r, C)it er - 
We clone the rewriting rules for decompose^ and decompose^- into refocusing rules, 
indexing their configurations as (c, C) cva i and (C, v) cont instead of as (c, C% e c/cios an d 
(C, w) dec/cont , respectively: 

• instead of rewriting to VAL (v), the cloned rules rewrite to v; 

• instead of rewriting to DEC (r, C), the cloned rules rewrite to (r, C)it e r- 
The result reads as follows: 
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(x[e\ 


, C) eva j — 


> (a; [el, C)i tcr 


\ \ s\Jb . L J 1 CI 


C) i - 

I Weval ~~ 


k in (\ r t)\ P ]\ , 




> Wcval 


> (1*0 *l)LeJ, G)iter 


(co Ci 


I C)eval — 


> (co, C[[] ci]) eva ] 


([] 


, v) cont = 




(C[[]ci], 


^o)cont = 


> (ci, C[f []])eval 


(C[v [}}, 


«l)cont = 


> (u Ul, C)iter 


(x[e\ 


) C)iter = 


> , C) Gval 


(((Xx.t)[e])v 


; C)iter = 


> (t[e'] 5 C) eva l 


{(to h)[e] 


; C);ter = 


* ((*o[e]) (iiN), C) evaJ 



if lookup(x, e) = v 
where e' = extend(x, v, e) 



The following proposition summarizes the situation: 

Proposition E.7. For any closure c, evaluate (c) = v if and only if (c, []) Gva i v - 
Proof: straightforward. The two machines operate in lockstep. 



□ 



E.2.3. Inlining and transition compression. The abstract machine of Section IE.2.21 while 
interesting in its own right (it is 'staged' in that the contraction rules are implemented 
separately from the congruence rules [14,69]), is not minimal: a number of transitions yield 
a configuration whose transition is uniquely determined. Let us carry out these hereditary, 
"corridor" transitions once and for all: 

• (x[e\, C) cva i (x[e\, C) itCT (v, C) cva i =4> (C, v) cont if lookup(x,e) = v 

• ((io*iM C) cva i ((Mi)N, C) iter ((t [e\) (h[e\), C) cval ((to[e]), C[[] (h[e})}) cval 

• (C[((Xx.t)[e\) [}], v) cont =4> \((Xx.t)[e]) v, C) itcr {t[e'], C) cval where e' = extend(x , v , e) 
The result reads as follows: 

(x[e], C) cva i (C, v) cont if lookup(x,e) = v 

((Xx.t)[e], C) cval (C, (Xx.t)[e]) mnt 
<(«oti)[e], C) eva] ((i [e]), C[[] (ti[e])]) eva i 

([], «)cont => l> 
(C[[] Ci], U )cont => (Cl, C[u []])evaJ 

(C[((Ax.t)[e]) []], u) cont (t[e'\, C) cva i where e' = extend(x, v, e) 

The configuration (r, C)it er has disappeared and so is the case for c$ c±: they were only 
transitory. 

Proposition E.8. For any closure c, evaluate (c) = v if and only if (c, []) CV ai v - 



Proof: immediate. We have merely compressed corridor transitions. 



□ 
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E.2.4. Opening closures: from explicit substitutions to terms and environments. The ab- 
stract machine above solely operates on ground closures. If we open the closures t[e] into 
pairs (t, e) and flatten the configuration {(t, e), C) cva i into a triple (t, e, C) cva i, we obtain an 
abstract machine that coincides with the caller-save, stackless CEK machine of Section TB, 21 

E.3. Conclusion and perspectives. Appendix [B] illustrated the functional correspon- 
dence between the functional implementation of a denotational or natural semantics and 
of an abstract machine, the CEK machine, for the A-calculus with left-to-right applicative 
order. The present appendix illustrates the syntactic correspondence between the func- 
tional implementation of a reduction semantics and of an abstract machine, again the CEK 
machine, for the A-calculus with left-to-right applicative order. Together, the functional 
correspondence and the syntactic correspondence therefore demonstrate the natural fit of 
the CEK machine in the semantic spectrum of the A-calculus with explicit substitutions 
and left-to-right applicative order. 
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